7 thoughts on “dart:io HttpClient’s request force-transforms the header names to lowercase

  1. If the RFC-2616 states that header names are case-insensitive… why force the header names transformation to lowercase? shouldn’t that be a decision taken by the developer?

  2. I’ve spent half a day debugging to find out http client forces headers as lowercase.
    Guess what, I’m stuck with 10 year old client devices with HTTP server’s using case sensitive headers.
    Why force anything? Let me decide what I want to send with MY request

  3. Since I can’t say to thousands of users to update their receivers or fix their HTTP server implementation, and I don’t expect Dart team to change this behavior, I had no other choice but to change default HTTP client.

    I took current HttpClient from master branch (requires Dart 2.5, Flutter 1.8+), changed it to leave headers alone and packed in the package. Hopefully it will save someone someone from crying and pulling up their hair. Just use it as a drop in replacement for HttpClient. Tested and works with Dio.

    You can find package HERE.

  4. Thats the one way to look at it.
    Why would HttpClient assume anything?
    You have bunch of Abstract classes in HTTP client that are used only as internal implementations. Take HttpHeaders for instance. It’s abstract, and HttpClient uses one single concrete implementation, which is internal, and has no way to use some other implementation.
    Why making abstract class in a first place if you’re forcing it to be used in a single way?
    Good and probably non breaking start would be to

    • move internal implementations to separate public classes/files
    • refactor existing calls to new classes
    • add a way for user to provide specific implementation of abstract class (not just HttpHeaders)
    • if no specific implementation is provided use default one

    Last two can be done as optional class constructor with default value params (better) or as public properties (less transparent IMHO).
    I’m speaking from top of my head now, but this shouldn’t breake anything.
    Dart has no reflection, and internal calls can be easily refactored.
    And once you’re there, in default HttpHeaders expose map of all headers as public property, leave current behaviour, as is, but let user modify the map directly however he/she wants. That’s extra, I’d be fine if I could make HttpClient use my HttpHeaders instead default ones.

    Just my 2 cents.

  5. reopening issue so that we can track when the bug fix CL lands and update on when it gets rolled into Flutter. You will probably see it in the dev channel first.

Comments are closed.