Support 103 Early Hints

[eygraber]

• [x] Feature Request. Start by telling us what problem you’re trying to solve. Often a solution already exists! Don’t send pull requests to implement new features without first getting our support. Sometimes we leave features out on purpose to keep the project small.

HTTP 103 Early Hints was just approved as a new response code. Are there any plans to offer support for it?

[swankjesse]

The programming model for early hints is substantially more complex. Rather than a single call yielding a single result it may now yield both an initial hints results and a later final result.

Building simple APIs around this will be difficult and I’m not in a particular rush to do so. If/when we do, it’ll probably take the form of some kind of extra callback.

[yschimke]

Won't fix.

[Yrlec]

Any plans to reconsider this now that Cloudflare is rolling out support across a large chunk of the web? https://blog.cloudflare.com/early-hints/ I'd be happy to assist if possible.

[yschimke]

The Cloudflare blog looks at using machine learning to automatically preload assets. This leaves me with a couple of questions

1. Do we think typical mobile traffic, or really anything a Java/Android client would be fetching will follow the same patterns that are most obvious with HTML request followed by CSS, JS or Images.
2. Do you have a concrete example for your own clients where this will clearly improve the response rate, particularly considering that overeagerly fetching assets would cause excessive use of network bandwidth?

[unlucku]

One thing to consider right now is that the way Cloudflare has implemented this, OkHttp errors out on the 103 request. I believe if you are using it for the sites that have it enabled, it gets stuck at response code 403 and unexpected bytes error at Exchange.kt. I have been able to solve the reading right now, just working on making it ignore the 103 (Supporting 103 will probably be a longer process, and overly complicated at that, I believe most users would simply want their clients to work like they did before)

[unlucku]

If anyone wants a solution that ignores 103 heres what I did if (!(headerBlockLength != 0 && headerBlock[0].value.utf8().equals("103"))) { handler.headers(endStream, streamId, -1, headerBlock) }

I added that to readHeaders function, its a crude solution but it works :). I believe the idea is that the first responseCode is not the only one, and we should go off the last response code, does that make sense to anyone?

[unlucku]

https://github.com/square/okhttp/commit/35f0dd9dbf2ae9ffcecc2b5fc86e11762a29bb4d This is what it looks like all together, I have used this since November and had no issues, if anyone urgently needs to get past this issue I think this can be good for you. However I dont really know kotlin so I am not sure if there are any unseen implications of this,

[yschimke]

The intent will be to support on 5.0 with clients notified of the early hints headers.

An early draft that is not 100% working https://github.com/square/okhttp/pull/7141

We should probably backport a similar approach to 4.9.x that ignores the headers.

[yschimke]

https://datatracker.ietf.org/meeting/98/materials/slides-98-httpbis-early-hints-00

RFC 7231: – (MUST) treat an unrecognized status code as being equivalent to the x00 status code of that class / the client can simply discard this interim response (for 100 continue) – a user agent MAY ignore unexpected 1xx responses