Ich, this is going to be long. I apologize in advance.
I'm having some trouble using HTTP::Request::Common to upload a PDF to a
web frontended document management system (Intradoc now know as Xerio,
IIRC). FWIW, Intradoc is IIS based.
The Good News: My script works.
The Bad: I had to hack HTTP/Request/Common.pm
I played a bit with DYNAMIC_FILE_UPLOAD=1 but that just caused my script to
hang when talking to IntraDoc. (Bad Content-Length?)
Here goes:
perl: 5.6.0
libwww-perl: 5.6.4
Common.pm Line 135-147
...
my $fh = Symbol::gensym();
open($fh, $file) or Carp::croak("Can't open file $file: $!");
binmode($fh);
if ($DYNAMIC_FILE_UPLOAD) {
# will read file later
$content = $fh;
} else {
local($/) = undef; # slurp files
$content = <$fh>;
close($fh);
#!!!!! $h->header("Content-Length" => length($content));
}
unless ($ct) {
...
What's the highlighted Content-Length header used for? This shows up in the
MIME header of the file portion:
--xYzZY
Content-Disposition: form-data; name="dDocName"
profbotTestV2
--xYzZY
Content-Disposition: form-data; name="primaryFile"; filename="notes.txt"
Content-Length: 702
Content-Type: text/plain
blah, blah, ...
Note that Mozilla (0.9.9) does not do this:
-----------------------------18042893838469308861681692777
Content-Disposition: form-data; name="dDocName"
pod1
-----------------------------18042893838469308861681692777
Content-Disposition: form-data; name="primaryFile"; filename="notes.txt"
Content-Type: text/plain
blah, blah, ...
I don't see this Content-Length required in any of the RFCs dealing with
multipart/form-data, only in the initial request headers sent as part of the
POST. I may very well have missed something, it was a brief skim.
If I comment out that line, everything works great. What gives me pause is
that ite seems to have been there for a rather looooong time so perhaps I'm
confused (more likely, it's a borken httpd). OTOH, requiring a custom patch
may not fly with the powers-that-be.
