http icon indicating copy to clipboard operation
http copied to clipboard

Add support for `preserveHeaderCase`

Open natebosch opened this issue 4 years ago • 6 comments

On the SDK we now have an option to pass preserveHeaderCase when setting Http headers to work around the default behavior of converting them all to lowercase. Some (non spec compliant?) servers expect headers with specific capitalization.

I don't know if there is any equivalent behavior or concern on the web.

Some design options:

  • An argument when constructing an IOClient to make the decision once at a client level.
    • Pro: Non breaking.
    • Con: Could be clumsy to use - cross platform code can't reference IOClient, may need to construct a specific client for some requests and a different client for others.
  • Add a named argument to all APIs.
    • Pro: fine-grained control by request.
    • Con: If the behavior can't be supported on the web we'd have to ignore the argument.
  • Preserve header case on the VM by default with no option to switch.
    • Con: Potentially breaking behavior change for existing users.

natebosch avatar Aug 17 '21 19:08 natebosch

We could also consider flipping the default in the next major version since it seems that most folks who care would prefer to preserve case.

natebosch avatar Sep 09 '21 19:09 natebosch

Hi, any progress with this one?

PiotrWpl avatar Dec 30 '21 14:12 PiotrWpl

@brianquinlan - WDYT about using preserveHeaderCase by default, and/or adding an option? I don't think this is something we can control on the web - is it possible on the other clients?

natebosch avatar Jan 12 '24 18:01 natebosch

Setting preserveHeaderCase: true for IOClient seems reasonable to me. But this isn't something that we should require of clients because:

  1. case insensitivity is required by RFC-2616
  2. some clients (e.g. package:cupertino_http) cannot promise to to preserve case because their underlying implementations are not case preserving

brianquinlan avatar Jan 12 '24 19:01 brianquinlan

  1. case insensitivity is required by RFC-2616

Yeah - it feels weird to have to add features that explicitly go off-spec, but buggy servers do exist so we may as well try to make the client as compatible as possible.

It sounds like the best path forward may be to default to preserving case for the IOClient, but to keep the option out of the interface. At most we can add an IO specific constructor arg if it becomes necessary.

I don't know how breaking we should consider this change if we do just flip the default.

natebosch avatar Jan 12 '24 19:01 natebosch