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 <[EMAIL PROTECTED]>: > 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 <[EMAIL PROTECTED]>: > > 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/"): > > > > > > >
