On 1 Aug 2013, at 12:30 PM, Niphlod <niph...@gmail.com> wrote:
> ok. so to be on the safe side if env.http_content_type and
> env.http_content_length are provided gluon.main should update the env
> accordingly, and then the code can happily always use env.content_length and
> env.content_type
That would be the idea. I don't actually like the extra complication, but the
thought that somebody might be relying on bogus behavior makes me just
*slightly* nervous.
I'd either to this (pseudo-code):
if not env.content_type and env.http_content_type:
env.content_type = env.http_content_type
...and so on. That is, don't touch variables that the server has already set.
I wouldn't argue to hard for not doing that, though, esp. if Massimo's OK with
leaving it out. Which would mean just changing our is_json test to look at
content_type. (I scanned the rest of the source, and that seems to be the only
place this happens.)
>
> On Thursday, August 1, 2013 9:21:28 PM UTC+2, Jonathan Lundell wrote:
> On 1 Aug 2013, at 12:11 PM, Niphlod <nip...@gmail.com> wrote:
>> ok, thanks for the additional explanation.
>>
>> tl;dr: As we don't "want to support" any breaking-spec servers (+1 on that),
>> the only thing to take care of is to rely for both content-type and
>> content-length headers to be directly on env and not expecting them to be
>> neither http_content_length nor http_content_type.
>>
>> did I get that clear ?
>
> Yes.
>
> I'm not sure I entirely agree about broken servers, though. Paraphrasing
> Postel's Law, ""Be conservative in what you send, be liberal in what you
> accept."
>
>>
>> On Thursday, August 1, 2013 9:03:34 PM UTC+2, Jonathan Lundell wrote:
>> On 1 Aug 2013, at 11:51 AM, Niphlod <nip...@gmail.com> wrote:
>>> @derek and @dhmorgan: actually what Iceberg posted is fine, it's really a
>>> subtle bug that needs to be addressed as per the docs posted by out own
>>> omniscient Jonathan, that can happen with some particular (although
>>> allowed) server architectures.
>>>
>>> @jonathan: before diving in rocket's own "patching of spec-breaking
>>> servers", is there any other header we need to address ?
>>>
>>>
>>
>> content_size is the other one in this category.
>>
>> A clarification, though: Rocket is not patching spec-breaking servers; it's
>> just a server complying with the spec, which mandates content_type if the
>> client has supplied one (which would optionally appear as http_content_type).
>>
>> A spec-breaking server would be one that does not include content_type when
>> one is provided by the client.
>>
>> The bug is that web2py relies on http_content_type, even though the spec
>> does not require the server to include it.
>>
>> My comment about working around a spec break is purely hypothetical, and
>> applies to the case where the client provides Content-Type, and the server
>> passes that along as http_content_type (as it should, but is not required to
>> do) and does not also pass it as content_type (which it *is* required to
>> do).
>>
--
---
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 web2py+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
