Your message dated Wed, 07 Aug 2013 22:07:57 +0000
with message-id <[email protected]>
and subject line [HTTP::Request::Common] MIME boundary value definition -
closing
has caused the Debian Bug report #516667,
regarding [HTTP::Request::Common] MIME boundary value definition
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
516667: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=516667
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
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);
===
--- End Message ---
--- Begin Message ---
Hi! I'm closing this bug, since it was tagged "wontfix" for some
years, without answer. If you have new reasons to point out this
problem, please feel free to re-open it.
--- End Message ---
