You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (go version)?
1.9
Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env)?
Linux amd64
What did you do?
Instantiating a multipart.Reader with an empty boundary, as might happen in the case of an invalid Content-Type header, such as the following:
Content-Type: multipart/related
does not result in an error. My reading of RFC 2046 suggests that the boundary must be at least one character:
The only mandatory global parameter for the "multipart" media type is
the boundary parameter, which consists of 1 to 70 characters from a
set of characters known to be very robust through mail gateways, and
NOT ending with white space.
What did you expect to see?
I would have expected an error on the first call to NextPart(), as the reader was instantiated with invalid sate.
What did you see instead?
No error.
Perhaps this isn't the right place to do such a check. Of note, there is also no check that the boundary conforms to any of the other constraints defined in RFC 2046. In particular, non-ASCII data is not guarded against, nor are boundaries greater than 70 characters in length.
The text was updated successfully, but these errors were encountered:
bradfitz
changed the title
Should multipart.Reader return an error for an empty (or otherwise invalid) boundary string?
mime/multipart: should Reader return an error for an empty (or otherwise invalid) boundary string?
Dec 18, 2017
bradfitz
added
the
NeedsDecision
Feedback is required from experts, contributors, and/or the community before a change can be made.
label
Dec 18, 2017
rsc
added
the
NeedsFix
The path to resolution is known, but the work has not been done.
label
Jan 29, 2018
gopherbot
removed
the
NeedsDecision
Feedback is required from experts, contributors, and/or the community before a change can be made.
label
Jan 29, 2018
rsc
changed the title
mime/multipart: should Reader return an error for an empty (or otherwise invalid) boundary string?
mime/multipart: diagnose missing boundary string
Jan 29, 2018
NewReader cannot return an error. It could eventually return nil when boundary is empty but no reason would be given. The proposed fix returns a relevant error on the first call of NextPart.
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (
go version
)?1.9
Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?Linux amd64
What did you do?
Instantiating a multipart.Reader with an empty boundary, as might happen in the case of an invalid Content-Type header, such as the following:
does not result in an error. My reading of RFC 2046 suggests that the boundary must be at least one character:
What did you expect to see?
I would have expected an error on the first call to
NextPart()
, as the reader was instantiated with invalid sate.What did you see instead?
No error.
Perhaps this isn't the right place to do such a check. Of note, there is also no check that the
boundary
conforms to any of the other constraints defined in RFC 2046. In particular, non-ASCII data is not guarded against, nor are boundaries greater than 70 characters in length.The text was updated successfully, but these errors were encountered: