HTTP header handling in the RSGI spec

[thrau]

Hi! First, I love the idea of having an iteration over ASGI as a spec! I haven't found a forum to discuss the RSGI spec in particular, feel free to direct me there.

I would like to challenge the way headers are currently defined in the RSGI spec.

• Data structure for headers Mapping[str, str]: HTTP Headers can have one or more values depending on the header field definitions, which is why many python web frameworks use a List[tuple[bytes, bytes]] data structure underneath, which is much more flexible (and appropriate to model the HTTP spec). making header access more user friendly via something like a mapping is IMO the responsibility of the framework built on top of the spec.
• Header casing: there's no clear definition of how header casing is handled. I would encourage the spec to consider raw headers by default. WSGI for instance, by design, has to manipulate header casing, which is terrible for building proxy servers. in ASGI it depends very much on the server implementation, and it has been discussed to change this but change is slow :-)

Just wanted to get an idea how far the spec is and how open it still is for discussions like these.

Thanks!

[gi0baro]

Hi @thrau, thank you for bringing up the discussion, RSGI is definitely green at this stage, so given there are valid reasons and that eventual breaking changes are handled properly, I think there's definitely room for changes which evolve the protocol.

At the moment there's no dedicated place to discuss about RSGI, eventually as the protocol gains some maturity and more widespread usage it might make sense to create some rsgispec package and move discussions on a dedicated repo.

Now, to address your questions:

• the reason for headers be a Mapping (actually I just opened RSGIHeaders out of spec #229, as you inadvertently spotted an out-of-spec issue here) is mainly due to the lower Rust data structure providing its contents. On top of this, the two major reasons the headers are not converted to a list are

  • performance, as we avoid the conversion cost unless explicitly requested
  • the fact that the majority of use cases out there access headers by key, thus a list is severely less performant than a dict for that

  Now, the actual issue I noticed here is that there's no way to access all the header values for a single key, which will be added by Allow to get all the header values for a single key in RSGIHeaders #230, and we might also add some as_list method to actually produce a list of tuples for intended use cases.

• You right, RSGI spec should specify the header casing policy (just opened Specify header casing policy in RSGI spec #231 to track this), which is currently always lower case. This is due to two main reasons:

  • in HTTP/2 this is the de-facto standard
  • all comparisons in HTTP/1.1 should be case insensitive

Let me know if you have any additional questions or feedbacks.