John Klar <[EMAIL PROTECTED]> writes:
> 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?
That is up to the server. It could potentially look at that field to
figure out if it wants to continue reading. If policy is that only
files under a certain size is accepted it could fail the request at
that point without reading it all.
I have a hard time understanding how a server app could be written so
that it fails because of an extra header field like this.
> 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.
No it is not required and not even suggested in the RFC. It is just
something I added for good measure because that information was
readily available. I thought it would not hurt.
> If I comment out that line, everything works great.
Could you check if things work if you rename the header name to
"X-Content-Length" or something. I want to know if the problem is any
kind of extra header or if there is something special with
"Content-Length" that this server app fails to grok.
Regards,
Gisle
