| Dominic Wong 2005-09-08, 2:46 am |
| 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.
|