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]<javascript:>> > 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.
