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