After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 614183 - multipart with three CRLF after last message-header causes problems in communication with some servers
multipart with three CRLF after last message-header causes problems in commun...
Status: RESOLVED FIXED
Product: libsoup
Classification: Core
Component: HTTP Transport
unspecified
Other All
: Normal normal
: ---
Assigned To: libsoup-maint@gnome.bugs
libsoup-maint@gnome.bugs
Depends on:
Blocks:
 
 
Reported: 2010-03-28 15:13 UTC by Egon Andersen
Modified: 2010-04-09 23:53 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Egon Andersen 2010-03-28 15:13:35 UTC
When using the multipart/form-data, libsoup uses three CRLF between last message-header and the -- in the first dash-boundary.

This causes responses with status-code 404 from some servers I try to upload files to.

According to RFC 2616
Section 4.1 Message Types
<cite>
        generic-message = start-line
                          *(message-header CRLF)
                          CRLF
                          [ message-body ]
        start-line      = Request-Line | Status-Line
</cite>
There should be two CRLF between last message-header and an optional message body.


According to RFC 2046
Section 5.1.1.  Common Syntax

<cite>
It is formally specified
   by the following BNF:

     boundary := 0*69<bchars> bcharsnospace

     bchars := bcharsnospace / " "

     bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" /
                      "+" / "_" / "," / "-" / "." /
                      "/" / ":" / "=" / "?"

   Overall, the body of a "multipart" entity may be specified as
   follows:

     dash-boundary := "--" boundary
                      ; boundary taken from the value of
                      ; boundary parameter of the
                      ; Content-Type field.

     multipart-body := [preamble CRLF]
                       dash-boundary transport-padding CRLF
                       body-part *encapsulation
                       close-delimiter transport-padding
                       [CRLF epilogue]

     transport-padding := *LWSP-char
                          ; Composers MUST NOT generate
                          ; non-zero length transport
                          ; padding, but receivers MUST
                          ; be able to handle padding
                          ; added by message transports.

     encapsulation := delimiter transport-padding
                      CRLF body-part

     delimiter := CRLF dash-boundary

     close-delimiter := delimiter "--"

     preamble := discard-text

     epilogue := discard-text

     discard-text := *(*text CRLF) *text
                     ; May be ignored or discarded.

     body-part := MIME-part-headers [CRLF *OCTET]
                  ; Lines in a body-part must not start
                  ; with the specified dash-boundary and
                  ; the delimiter must not appear anywhere
                  ; in the body part.  Note that the
                  ; semantics of a body-part differ from
                  ; the semantics of a message, as
                  ; described in the text.

     OCTET := <any 0-255 octet value>
</cite>

multipart-body starts with an optional 'preamble CRLF', which is not used by libsoup, followed by a 'dash-boundary'.

A 'dash-boundary' do *not* start with a CRLF.

According to RFC 2616
Section 3.7.2 Multipart Types
<cite>
The message body is itself a protocol element and MUST therefore use only CRLF to represent line breaks between body-parts.
</cite>

I believe this together means that the correct handling of multipart types must be that the last message-header is followed by two CRLF followed by two hyphens followed by the boundary, and not three CRLF as seen in libsoup today.

This could fixed in sooup-multipart.c in function soup_multipart_to_message () by adding some test whether it is the first body and then use 'dash-boundary', otherwise use 'delimiter' as specified in RFC 2046 Section 5.1.1.  Common Syntax, cited above.
Comment 1 Dan Winship 2010-04-09 23:53:33 UTC
fixed in master, will go into 2.30.1