application/octet-stream and empty fileinputs

am 04.03.2006 01:05:31 von ekolve

------=_Part_16829_32400037.1141430731727
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

I noticed that if you submit an HTML::Form that it doesn't set the
content-type for empty fileinputs to application/octet-stream. I am not
sure if this is legal or not. I compared dumps of firefox vs. LWP and it
looks like firefox does set the content-type even if you don't have anythin=
g
for the input stream. I suppose since the content is empty you *SHOULDN'T*
have to set a content-type, but I am curious to hear opinions on whether
this should be changed.

thanks,
eric

------=_Part_16829_32400037.1141430731727--

Re: application/octet-stream and empty fileinputs

am 04.03.2006 10:49:56 von gisle

"Eric Kolve" writes:

> I noticed that if you submit an HTML::Form that it doesn't set the
> content-type for empty fileinputs to application/octet-stream. I am not
> sure if this is legal or not.

The reported content type is determined by looking at the file name
extension and if not recongnized by what perl's -T builtin thinks. On
my system -T regards empty files as text, so empty files are reported
as text/plain.

This program:

use HTML::Form;
my $f = HTML::Form->parse(<

EOT
print $f->click->as_string;

will for instance print:

POST http://www.example.com
Content-Length: 114
Content-Type: multipart/form-data; boundary=xYzZY

--xYzZY
Content-Disposition: form-data; name="f"; filename="/dev/null"
Content-Type: text/plain

--xYzZY--

Your message seems to indicate that you get no Content-Type at all.
Please provide some example code that demonstrates how you use the
module.

> I compared dumps of firefox vs. LWP and it
> looks like firefox does set the content-type even if you don't have anything
> for the input stream. I suppose since the content is empty you *SHOULDN'T*
> have to set a content-type, but I am curious to hear opinions on whether
> this should be changed.

If you find differences that make real world applications break with
LWP that works with Firefox then I would certainly like to fix LWP.

Regards,
Gisle

Re: application/octet-stream and empty fileinputs

am 04.03.2006 19:34:04 von ekolve

------=_Part_337_22466290.1141497244551
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

I was essentially doing this:

use HTML::Form;

my $f =3D HTML::Form->parse(<

EOT

print $f->click->as_string

I don't think it's a real big deal to not have the content-type since
nothing is being submitted, though I am curious what compelled the Mozilla
people to set it to octet-stream when nothing had been selected.

On 04 Mar 2006 01:49:56 -0800, Gisle Aas wrote:
>
> "Eric Kolve" writes:
>
> > I noticed that if you submit an HTML::Form that it doesn't set the
> > content-type for empty fileinputs to application/octet-stream. I am no=
t
> > sure if this is legal or not.
>
> The reported content type is determined by looking at the file name
> extension and if not recongnized by what perl's -T builtin thinks. On
> my system -T regards empty files as text, so empty files are reported
> as text/plain.
>
> This program:
>
> use HTML::Form;
> my $f =3D HTML::Form->parse(< >
> EOT
> print $f->click->as_string;
>
> will for instance print:
>
> POST http://www.example.com
> Content-Length: 114
> Content-Type: multipart/form-data; boundary=3DxYzZY
>
> --xYzZY
> Content-Disposition: form-data; name=3D"f"; filename=3D"/dev/null"
> Content-Type: text/plain
>
>
> --xYzZY--
>
> Your message seems to indicate that you get no Content-Type at all.
> Please provide some example code that demonstrates how you use the
> module.
>
> > I compared dumps of firefox vs. LWP an=
d
> it
> > looks like firefox does set the content-type even if you don't have
> anything
> > for the input stream. I suppose since the content is empty you
> *SHOULDN'T*
> > have to set a content-type, but I am curious to hear opinions on whethe=
r
> > this should be changed.
>
> If you find differences that make real world applications break with
> LWP that works with Firefox then I would certainly like to fix LWP.
>
> Regards,
> Gisle
>

------=_Part_337_22466290.1141497244551--