- From: Mitar <mmitar@gmail.com>
- Date: Fri, 5 Apr 2024 12:59:43 +0200
- To: HTTP Working Group <ietf-http-wg@w3.org>
Hi! I know I am late in the draft-ietf-httpbis-sfbis process, but after using for some time now both RFC 8941 and sfbis extensions, I wanted to share my experience. I really like it, It is great to have a standard way to pass values in headers to clients. It is great that it is compatible with how most other standards are doing it. It is great that it is typed. But ... the requirement that keys should be only lower case (section 4.1.1.3) really makes it hard to be interoperable with existing ways to encode data structures. It makes it tricky to write idiomatic data structures in many languages which use camelCase and then convert that structure into structured field values. For example, if you want idiomatic JavaScript objects on both server side (where you are sending the header) and client side (where you are reading it), you have to encode it as snake_case or something. Or ask all users creating the data structure to use snake_case to begin with. But in my app I want to pass some metadata to the client and I want the app itself to decide which fields go into JSON response and which fields into HTTP header. There is unnecessary friction here. I would really urge that this is relaxed in one of future versions and upper case ASCII to be allowed as well. I know that this is primarily cosmetic, but it would make different languages and libraries easier to work together. I understand that there are probably strong reasons for this decision and that this has probably been discussed already, but I just wanted to share my experiences with in my view unnecessary friction. Thank you for great work on the sfbis, Mitar -- https://mitar.tnode.com/ https://twitter.com/mitar_m https://noc.social/@mitar
Received on Friday, 5 April 2024 10:59:59 UTC