Internet WorkShop

Ok, that sounds a bit complex, but basically if you have data such as

POST https://someurl
Content-Length: 503
Content-Type: multipart/form-data; boundary=xYzZY

–xYzZY
Content-Disposition: form-data; name=”someFile”; filename=”somefile”
Content-Type: text/plain

lines in
somefile

–xYzZY
Content-Disposition: form-data; name=”otherFile”; filename=”otherfile”
Content-Type: text/plain

lines in
otherfile

–xYzZY

Content-Disposition: form-data; name=”RegularData”
Content-Type: text/xml

<RegularData>
<Parameter1>Data1</Parameter1>
<Parameter2>value number two</Parameter2>
</RegularData>
–xYzZY–

and you use CGI.pm to process it, there is NO WHERE in the query object returned by CGI->new that stores the fact that RegularData is Content-type: text/xml. You can see this in the CGI.pm code here:

if ( ( !defined($filename) || $filename eq '' ) && !$multipart ) {
my($value) = $buffer->readBody;
$value .= $TAINTED;
push(@{$self->{param}{$param}},$value);
next;
}

The only place that knew about the Content-type: text/xml was in %header, a local variable that goes out of scope when we go to the next parameter.

Not a huge deal, but sometimes it matters...could patch CGI.pm, use some other method of parsing the multipart data, or guess the format by inspection...probably I'll be lazy and inspect the data.

This is for CGI.pm version 3.51 and 3.60