Package: libwww-perl Version: 5.820-1 Does the way it defines MIME multipart boundary values in Content-Type header is much compatible? While LWP is always setting something like: Content-Type: multipart/form-data; boundary=GTXZ7WqgwvYfDGRBbLlgTxQIWXsMmlXOvrD6pDEe, I've noted that many other applications are using hyphens prefixed boundary values in the header. I've faced this incompatiblity (?) when writing LWP based RapidShare upload script, RS server software persistently denies any POST requests with LWP's boundary values.
Citing section 7.2.1 of RFC 1341 (http://www.w3.org/Protocols/rfc1341/7_2_Multipart.html): === The Content-Type field for multipart entities requires one parameter, "boundary", which is used to specify the encapsulation boundary. The encapsulation boundary is defined as a line consisting entirely of two hyphen characters ("-", decimal code 45) followed by the boundary parameter value from the Content-Type header field. NOTE: The hyphens are for rough compatibility with the earlier RFC 934 method of message encapsulation, and for ease of searching for the boundaries in some implementations. However, it should be noted that multipart messages are NOT completely compatible with RFC 934 encapsulations; in particular, they do not obey RFC 934 quoting conventions for embedded lines that begin with hyphens. This mechanism was chosen over the RFC 934 mechanism because the latter causes lines to grow with each level of quoting. The combination of this growth with the fact that SMTP implementations sometimes wrap long lines made the RFC 934 mechanism unsuitable for use in the event that deeply-nested multipart structuring is ever desired. === Simpliest patch is getting things normal for my purposes: === --- Common.pm~ 2009-02-22 22:47:53.000000000 +0000 +++ Common.pm 2009-02-22 22:53:03.000000000 +0000 @@ -69,7 +69,7 @@ $v[$boundary_index] = $boundary; } else { - push(@v, boundary => $boundary); + push(@v, boundary => '--' . $boundary); } $ct = HTTP::Headers::Util::join_header_words(@v); === -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
