+1 for the proposed fix. I learned something new in the process ^_^ PS @all: I'd like to backport web3py lazy request.vars, request.get_vars, request.post_vars, request.cookies, and request.env to web2py starting from tomorrow. If other things like this should be patched in globals.py or in main.py, I think it would be a good occasion to fix once and for all.
On Thursday, August 1, 2013 5:44:58 PM UTC+2, Ray (a.k.a. Iceberg) wrote: > > > > On Thursday, August 1, 2013 11:38:17 PM UTC+8, Jonathan Lundell wrote: >> >> On 1 Aug 2013, at 7:25 AM, "Ray (a.k.a. Iceberg)" <[email protected]> wrote: >> >> Thanks for trying to help Niphlod. More details so far. >> >> Strangely, that problem does NOT exist when I test with >> http://web2py.com/examples/simple_examples/status >> >> So I compare the output page between mine and the one from web2py.com, >> then I found something. >> >> On my server's output, there are only TWO appearances of >> "application/json", one in request.env.content_type and another in >> request.wsgi.environ.CONTENT_TYPE. >> >> On web2py.com's output, there are FOUR appearances of >> "application/json", they are request.env.content_type, >> request.env.http_content_type, request.wsgi.environ.CONTENT_TYPE, and >> request.wsgi.environ.HTTP_CONTENT_TYPE. >> >> And turns out line 343 of parse_get_post_vars() uses only >> "http_content_type" to trigger the json support. >> http://code.google.com/p/web2py/source/browse/gluon/main.py >> >> No wonder the symptom. So the next question is, what makes the >> request.env.http_content_type missing in my case? Is it somehow because my >> apache sits behind an nginx (a webfaction convention) so the >> request.is_local >> is always True (which is not the case of web2py.com)? >> >> Or, shall we simply change that line 343 of gluon/main.py into this: >> >> >> >> is_json = (env.get('http_content_type', '') >> or env.get('content_type', '') >> )[:16] == 'application/json' >> >> >> Thoughts? >> >> >> The specs associated with the Content-Type header are a little >> complicated. WSGI inherits them from CGI. >> >> The general idea is that (if the protocol is http), the environ members >> beginning with http_ were supplied by the client. Headers not starting with >> http_ are supplied by the server (possibly based on client headers). >> >> The bottom line: the server is required to provide content_type if the >> client supplies one (otherwise it's optional); it is *not* required to >> supply the client header http_content_type. >> >> GGI/1.1: http://ken.coar.org/cgi/draft-coar-cgi-v11-03.txt >> >> 6.1.3. CONTENT_TYPE >> ... >> Servers MUST provide this metavariable to scripts if a >> "Content-Type" field was present in the original request >> header. If the server receives a request with an attached >> entity but no "Content-Type" header field, it MAY attempt to >> determine the correct datatype, or it MAY omit this >> metavariable when communicating the request information to the >> script. >> >> 6.1.5. Protocol-Specific Metavariables >> ... >> Metavariables with names beginning with "HTTP_" contain values >> from the request header, if the scheme used was HTTP. Each >> HTTP header field name is converted to upper case, has all >> occurrences of "-" replaced with "_", and has "HTTP_" >> prepended to form the metavariable name. >> ... >> Servers are not required to create metavariables for all the >> request header fields that they receive. In particular, they >> MAY decline to make available any header fields carrying >> authentication information, such as "Authorization", or which >> are available to the script via other metavariables, such as >> "Content-Length" and "Content-Type". >> >> Rocket, for example, complies: >> >> if 'HTTP_CONTENT_TYPE' in environ: >> environ['CONTENT_TYPE'] = environ['HTTP_CONTENT_TYPE'] >> >> >> So, if anything, web2py should be looking at content_type only; it's a >> mistake to look at http_content_type only, and (by spec) unnecessary to >> look at http_content_type at all. >> >> If we're really worried about spec-breaking servers, we could repeat the >> Rocket logic (above) early on incoming requests (and the same for >> content_length, which has similar rules). >> > > > Sounds convincing! So it is a bug need to be fixed. Let's see how Massimo > or others say. > -- --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
