Class: Net::IMAP::BodyTypeAttachment
Relationships & Source Files | |
Super Chains via Extension / Inclusion / Inheritance | |
Class Chain:
self,
Struct
|
|
Instance Chain:
self,
Struct
|
|
Inherits: |
Struct
|
Defined in: | lib/net/imap/response_data.rb |
Overview
BodyTypeAttachment
is not used and will be removed in an upcoming release.
Bug Analysis
IMAP body structures are parenthesized lists and assign their fields positionally, so missing fields change the intepretation of all following fields. Additionally, different body types have a different number of required fields, followed by optional “extension” fields.
BodyTypeAttachment
was previously returned when a “message/rfc822” part, which should be sent as body-type-msg
with ten required fields, was actually sent as a body-type-basic
with seven required fields.
basic => type, subtype, param, id, desc, enc, octets, md5=nil, dsp=nil, lang=nil, loc=nil, *ext
msg => type, subtype, param, id, desc, enc, octets, envelope, body, lines, md5=nil, ...
Normally, envelope
and md5
are incompatible, but ::Net::IMAP
leniently allowed buggy servers to send NIL
for envelope
. As a result, when a server sent a message/rfc822
part with NIL
for md5
and a non-NIL
dsp
, ::Net::IMAP
mis-interpreted the Content-Disposition
as if it were a strange body type. In all reported cases, the Content-Disposition
was “attachment”, so BodyTypeAttachment
was created as the workaround.
Current behavior
When interpreted strictly, envelope
and md5
are incompatible. So the current parsing algorithm peeks ahead after it has recieved the seventh body field. If the next token is not the start of an envelope
, we assume the server has incorrectly sent us a body-type-basic
and return BodyTypeBasic
. As a result, what was previously BodyTypeMessage#body => BodyTypeAttachment
is now BodyTypeBasic#disposition => ContentDisposition
.
Instance Attribute Summary
-
#_unused_
rw
BodyTypeAttachment
is not used and will be removed in an upcoming release. -
#dsp_type
rw
BodyTypeAttachment
is not used and will be removed in an upcoming release. - #multipart? ⇒ Boolean readonly
-
#param
rw
BodyTypeAttachment
is not used and will be removed in an upcoming release.
Instance Method Summary
-
#media_type
*invalid for BodyTypeAttachment*.
-
#subtype
*invalid for BodyTypeAttachment*.
Instance Attribute Details
#_unused_ (rw)
BodyTypeAttachment
is not used and will be removed in an upcoming release.
Bug Analysis
IMAP body structures are parenthesized lists and assign their fields positionally, so missing fields change the intepretation of all following fields. Additionally, different body types have a different number of required fields, followed by optional “extension” fields.
BodyTypeAttachment
was previously returned when a “message/rfc822” part, which should be sent as body-type-msg
with ten required fields, was actually sent as a body-type-basic
with seven required fields.
basic => type, subtype, param, id, desc, enc, octets, md5=nil, dsp=nil, lang=nil, loc=nil, *ext
msg => type, subtype, param, id, desc, enc, octets, envelope, body, lines, md5=nil, ...
Normally, envelope
and md5
are incompatible, but ::Net::IMAP
leniently allowed buggy servers to send NIL
for envelope
. As a result, when a server sent a message/rfc822
part with NIL
for md5
and a non-NIL
dsp
, ::Net::IMAP
mis-interpreted the Content-Disposition
as if it were a strange body type. In all reported cases, the Content-Disposition
was “attachment”, so BodyTypeAttachment
was created as the workaround.
Current behavior
When interpreted strictly, envelope
and md5
are incompatible. So the current parsing algorithm peeks ahead after it has recieved the seventh body field. If the next token is not the start of an envelope
, we assume the server has incorrectly sent us a body-type-basic
and return BodyTypeBasic
. As a result, what was previously BodyTypeMessage#body => BodyTypeAttachment
is now BodyTypeBasic#disposition => ContentDisposition
.
#dsp_type (rw)
BodyTypeAttachment
is not used and will be removed in an upcoming release.
Bug Analysis
IMAP body structures are parenthesized lists and assign their fields positionally, so missing fields change the intepretation of all following fields. Additionally, different body types have a different number of required fields, followed by optional “extension” fields.
BodyTypeAttachment
was previously returned when a “message/rfc822” part, which should be sent as body-type-msg
with ten required fields, was actually sent as a body-type-basic
with seven required fields.
basic => type, subtype, param, id, desc, enc, octets, md5=nil, dsp=nil, lang=nil, loc=nil, *ext
msg => type, subtype, param, id, desc, enc, octets, envelope, body, lines, md5=nil, ...
Normally, envelope
and md5
are incompatible, but ::Net::IMAP
leniently allowed buggy servers to send NIL
for envelope
. As a result, when a server sent a message/rfc822
part with NIL
for md5
and a non-NIL
dsp
, ::Net::IMAP
mis-interpreted the Content-Disposition
as if it were a strange body type. In all reported cases, the Content-Disposition
was “attachment”, so BodyTypeAttachment
was created as the workaround.
Current behavior
When interpreted strictly, envelope
and md5
are incompatible. So the current parsing algorithm peeks ahead after it has recieved the seventh body field. If the next token is not the start of an envelope
, we assume the server has incorrectly sent us a body-type-basic
and return BodyTypeBasic
. As a result, what was previously BodyTypeMessage#body => BodyTypeAttachment
is now BodyTypeBasic#disposition => ContentDisposition
.
#multipart? ⇒ Boolean
(readonly)
[ GitHub ]
# File 'lib/net/imap/response_data.rb', line 1107
def multipart? return false end
#param (rw)
BodyTypeAttachment
is not used and will be removed in an upcoming release.
Bug Analysis
IMAP body structures are parenthesized lists and assign their fields positionally, so missing fields change the intepretation of all following fields. Additionally, different body types have a different number of required fields, followed by optional “extension” fields.
BodyTypeAttachment
was previously returned when a “message/rfc822” part, which should be sent as body-type-msg
with ten required fields, was actually sent as a body-type-basic
with seven required fields.
basic => type, subtype, param, id, desc, enc, octets, md5=nil, dsp=nil, lang=nil, loc=nil, *ext
msg => type, subtype, param, id, desc, enc, octets, envelope, body, lines, md5=nil, ...
Normally, envelope
and md5
are incompatible, but ::Net::IMAP
leniently allowed buggy servers to send NIL
for envelope
. As a result, when a server sent a message/rfc822
part with NIL
for md5
and a non-NIL
dsp
, ::Net::IMAP
mis-interpreted the Content-Disposition
as if it were a strange body type. In all reported cases, the Content-Disposition
was “attachment”, so BodyTypeAttachment
was created as the workaround.
Current behavior
When interpreted strictly, envelope
and md5
are incompatible. So the current parsing algorithm peeks ahead after it has recieved the seventh body field. If the next token is not the start of an envelope
, we assume the server has incorrectly sent us a body-type-basic
and return BodyTypeBasic
. As a result, what was previously BodyTypeMessage#body => BodyTypeAttachment
is now BodyTypeBasic#disposition => ContentDisposition
.
Instance Method Details
#media_type
*invalid for BodyTypeAttachment*
# File 'lib/net/imap/response_data.rb', line 1079
def media_type warn(<<~WARN, uplevel: 1) BodyTypeAttachment#media_type is obsolete. Use dsp_type instead. WARN dsp_type end
#subtype
*invalid for BodyTypeAttachment*
# File 'lib/net/imap/response_data.rb', line 1087
def subtype warn("BodyTypeAttachment#subtype is obsolete.\n", uplevel: 1) nil end