You are viewing a plain text version of this content. The canonical link for it is here.
Posted to mod_python-dev@quetz.apache.org by Dominic Wong <do...@syd.microforte.com.au> on 2005/09/08 07:42:09 UTC
Re: Possible Bug? Util.FieldStorage and the handling of content-type
Hi,
This was reported in 2003, and as far as I can tell the behaviour is
still present in util.py:
The full format of the media-type element according to RFC2616 is:
<snip>
media-type = type "/" subtype *( ";" parameter )
type = token
subtype = token
</snip>
There are many user agents out there that use this extra parameter when
posting data; Series 60 Symbian phones are the ones I'm concerned with
atm, but I have also seen evidence of other browsers doing this as well.
I believe that at the very least it should not assume that the entire
Content-Type string is going to be either
"application/x-www-form-urlencoded" or starting with "multipart/", that
it should be more tolerant towards parameters.
I have supplied a patch for lib/python/mod_python/util.py against the
3.2.1 beta version; if someone could let me know if it is an acceptable
solution or not, that would be great.
Thanks!
Dominic Wong
James Baster wrote:
> Hey,
>
> Is this a bug? I found it while attempting to integrate worldpay
> into a solution for a client that uses Mod-Python.
>
> Basically, util.fieldstorage looks at the content-type header. If
> its a "multi/*", it starts doing things with that. If it is
> "application/x-www-form-urlencoded", it splits the POST parameters as
> it is meant to. Otherwise, the code raises an error.
>
> However, worldpay passes a content-type value of "Content-Type:
> application/x-www-form-urlencoded; charset=ISO-8859-1". This causes
> problems, as util.fieldstorage refuses to recongise it.
>
> The solution I have temporarily put in place in our code is these two
> lines, directly before calling util.fieldstorage:
>
> t = split(request.headers_in["Content-Type"], ";")
> request.headers_in["content-type"] = t[0]
>
> I think this is safe, as there is no legitimate Content-type with a
> semi-colon character in it - so this fix should not break anything
> else. If it does, please let me know!
>
> However, my view is that util.fieldstorage should be able to handle
> this by itself.
>
> So anyway, I'm just reporting this issue for you to decide if it is
> a bug or not.
> Feel free to email with any comments ...
> Thanks,
> James.
Re: Possible Bug? Util.FieldStorage and the handling of content-type
Posted by Nicolas Lehuen <ni...@gmail.com>.
Er, just as a notice, the second test for "multipart/" was already
correct, but I've changed it to 'not ctypes.startswith("multipart/")'
for better code consistency.
Regards,
Nicolas
2005/9/8, Nicolas Lehuen <ni...@gmail.com>:
> Hi Dominic,
>
> That's perfectly acceptable. I've just used the startswith method of
> the str class instead of the lambda function you used. I've checked in
> the fix, hopefully it will appear in the next beta release.
>
> Regards,
> Nicolas
>
> 2005/9/8, Dominic Wong <do...@syd.microforte.com.au>:
> > Hi,
> >
> > This was reported in 2003, and as far as I can tell the behaviour is
> > still present in util.py:
> >
> > The full format of the media-type element according to RFC2616 is:
> >
> > <snip>
> > media-type = type "/" subtype *( ";" parameter )
> > type = token
> > subtype = token
> > </snip>
> >
> > There are many user agents out there that use this extra parameter when
> > posting data; Series 60 Symbian phones are the ones I'm concerned with
> > atm, but I have also seen evidence of other browsers doing this as well.
> >
> > I believe that at the very least it should not assume that the entire
> > Content-Type string is going to be either
> > "application/x-www-form-urlencoded" or starting with "multipart/", that
> > it should be more tolerant towards parameters.
> >
> > I have supplied a patch for lib/python/mod_python/util.py against the
> > 3.2.1 beta version; if someone could let me know if it is an acceptable
> > solution or not, that would be great.
> >
> > Thanks!
> >
> > Dominic Wong
> >
> >
> > James Baster wrote:
> >
> > > Hey,
> > >
> > > Is this a bug? I found it while attempting to integrate worldpay
> > > into a solution for a client that uses Mod-Python.
> > >
> > > Basically, util.fieldstorage looks at the content-type header. If
> > > its a "multi/*", it starts doing things with that. If it is
> > > "application/x-www-form-urlencoded", it splits the POST parameters as
> > > it is meant to. Otherwise, the code raises an error.
> > >
> > > However, worldpay passes a content-type value of "Content-Type:
> > > application/x-www-form-urlencoded; charset=ISO-8859-1". This causes
> > > problems, as util.fieldstorage refuses to recongise it.
> > >
> > > The solution I have temporarily put in place in our code is these two
> > > lines, directly before calling util.fieldstorage:
> > >
> > > t = split(request.headers_in["Content-Type"], ";")
> > > request.headers_in["content-type"] = t[0]
> > >
> > > I think this is safe, as there is no legitimate Content-type with a
> > > semi-colon character in it - so this fix should not break anything
> > > else. If it does, please let me know!
> > >
> > > However, my view is that util.fieldstorage should be able to handle
> > > this by itself.
> > >
> > > So anyway, I'm just reporting this issue for you to decide if it is
> > > a bug or not.
> > > Feel free to email with any comments ...
> > > Thanks,
> > > James.
> >
> >
> >
> >
> >
> > 116a117,118
> > > startsWith = lambda string, start: string[:len(start)] == start
> > >
> > 122c124
> > < if ctype == "application/x-www-form-urlencoded":
> > ---
> > > if startsWith(ctype, "application/x-www-form-urlencoded"):
> > 129c131
> > < if ctype[:10] != "multipart/":
> > ---
> > > if not startsWith(ctype, "multipart/"):
> >
> >
> >
>
Re: Possible Bug? Util.FieldStorage and the handling of content-type
Posted by Nicolas Lehuen <ni...@gmail.com>.
Hi Dominic,
That's perfectly acceptable. I've just used the startswith method of
the str class instead of the lambda function you used. I've checked in
the fix, hopefully it will appear in the next beta release.
Regards,
Nicolas
2005/9/8, Dominic Wong <do...@syd.microforte.com.au>:
> Hi,
>
> This was reported in 2003, and as far as I can tell the behaviour is
> still present in util.py:
>
> The full format of the media-type element according to RFC2616 is:
>
> <snip>
> media-type = type "/" subtype *( ";" parameter )
> type = token
> subtype = token
> </snip>
>
> There are many user agents out there that use this extra parameter when
> posting data; Series 60 Symbian phones are the ones I'm concerned with
> atm, but I have also seen evidence of other browsers doing this as well.
>
> I believe that at the very least it should not assume that the entire
> Content-Type string is going to be either
> "application/x-www-form-urlencoded" or starting with "multipart/", that
> it should be more tolerant towards parameters.
>
> I have supplied a patch for lib/python/mod_python/util.py against the
> 3.2.1 beta version; if someone could let me know if it is an acceptable
> solution or not, that would be great.
>
> Thanks!
>
> Dominic Wong
>
>
> James Baster wrote:
>
> > Hey,
> >
> > Is this a bug? I found it while attempting to integrate worldpay
> > into a solution for a client that uses Mod-Python.
> >
> > Basically, util.fieldstorage looks at the content-type header. If
> > its a "multi/*", it starts doing things with that. If it is
> > "application/x-www-form-urlencoded", it splits the POST parameters as
> > it is meant to. Otherwise, the code raises an error.
> >
> > However, worldpay passes a content-type value of "Content-Type:
> > application/x-www-form-urlencoded; charset=ISO-8859-1". This causes
> > problems, as util.fieldstorage refuses to recongise it.
> >
> > The solution I have temporarily put in place in our code is these two
> > lines, directly before calling util.fieldstorage:
> >
> > t = split(request.headers_in["Content-Type"], ";")
> > request.headers_in["content-type"] = t[0]
> >
> > I think this is safe, as there is no legitimate Content-type with a
> > semi-colon character in it - so this fix should not break anything
> > else. If it does, please let me know!
> >
> > However, my view is that util.fieldstorage should be able to handle
> > this by itself.
> >
> > So anyway, I'm just reporting this issue for you to decide if it is
> > a bug or not.
> > Feel free to email with any comments ...
> > Thanks,
> > James.
>
>
>
>
>
> 116a117,118
> > startsWith = lambda string, start: string[:len(start)] == start
> >
> 122c124
> < if ctype == "application/x-www-form-urlencoded":
> ---
> > if startsWith(ctype, "application/x-www-form-urlencoded"):
> 129c131
> < if ctype[:10] != "multipart/":
> ---
> > if not startsWith(ctype, "multipart/"):
>
>
>