application/octet-stream and empty fileinputs
------=_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
"Eric Kolve" <ekolve [at] gmail.com> 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, "http://www.example.com");
<form method="POST" enctype="multipart/form-data">
<input name=f value="/dev/null" type="file">
</form>
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
------=_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, "http://www.example.com");
<form method=3D"POST" enctype=3D"multipart/form-data">
<input name=3Df value=3D"" type=3D"file">
</form>
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 <gisle [at] activestate.com> wrote:
>
> "Eric Kolve" <ekolve [at] gmail.com> 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, "http://www.example.com");
> <form method=3D"POST" enctype=3D"multipart/form-data">
> <input name=3Df value=3D"/dev/null" type=3D"file">
> </form>
> 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--