On 1 Aug 2013, at 12:11 PM, Niphlod <[email protected]> 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 <[email protected]> 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
