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). -- --- 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.
