Intent: 103 Early Hints for HTTP/1.1

[Hoang Tran]

Hi everyone,

For the research purpose, I am trying to implement Early Hints support
for HTTP/1.1.

As the first step, I played with preload Link header in Chrome. The
local setup uses nghttpx as the server since it supports Early Hints,
and I tried different scenarios:

A) Original Chrome: the server responses a 200 status code with a Link
preload header and full HTML body.
Chrome does fetching for the requested asset in
LinkLoader::LoadLinksFromHeader() in DocumentLoader, when it consumes
the response's body. Stack trace is here https://pastebin.com/ungRYe4s

B) Patched Chrome: in HttpStreamParser, I changed the parser to not
ignore 103 status response. (The patch is in the attachment)
With this change, Chrome treats 103 response as if it is a 200
status response.

Now, LinkLoader::LoadLinksFromHeader() is also called, when
URLLoader completed. Stack trace is here https://pastebin.com/zz5GuWGY
But here the Link header_value in the response object is empty, and
so the fetching for preload asset is never done.

So my question is, in scenario A, where Chrome stores the response's
Link header (which never happened in scenario B)?

And if I am able to make fetching works for scenario B, would the
preloaded assets are still relevant after getting main 200 OK response?

Chrome is new to me, so if you have any other suggestion, it will be
also very appreciated.

Thank you for all your help!

Regards,

Hoang

[Matt Menke]

Are the response headers making it to LinkLoader for the 103 response or for the subsequent 200 response?  If it's the 200 response, HttpNetworkTransaction also has some magic for 1xx responses.  You may be running into that.  Not sure what the cache layer would make of those responses, either.

The entire network stack and everything hanging off of it only expects one set of response headers per request (Redirect response headers follow another route, once they hit the URLRequestJob layer), so it's unclear what else will break if you violate that assumption.  There are a lot of things between HttpStreamParser and blink's loading code that are interested in response headers.

You may be best served by working on content_shell instead of chrome, since there's so much less random stuff there dangling precariously off of the network stack.

--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+unsubscribe@chromium.org.
To post to this group, send email to net...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/f08d1de0-7dc9-470e-8da3-d13d7cff133f%40uclouvain.be.

[Charles Harrison]

chromium-dev -> bcc

+loading-dev

+yoav

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAEK7mvpsrcpjdFNhkj7qf%3D66p621w5AW0zhtwV9SQWehVQRoEA%40mail.gmail.com.

[Hoang Tran]

Hello Matt,

Thank you for the response,

In scenario B, I do not put the Link header in the 200 response (this is for testing, I know it is not compliant with the Early Hints spec).
But on the wire, the 103 and 200 status headers are in the same TCP segment, due to a limitation of nghttpx-mruby, so Chrome may get confused. I am searching for a better control on server side, so any recommendation is also appreciated.

Thanks for the suggestion about using content_shell. I was not aware of it before but will give it a try.

Regards,
Hoang

[Matt Menke]

Reading the 103 and 200 headers together shouldn't be a problem, at least for the old code.  The test HttpNetworkTransactionTest.Ignores1xx tests just this case.

One thing I often find useful to do is to write unit tests to better understand what's going on.  Obviously if you're not planning on landing anything, unit tests aren't strictly necessary, but figuring out where things are going wrong can be simpler in a unit test environment, instead of in a full browser.  You may want to modify the aforementioned test (Or the one just above it, which simulates receiving the 1xx and 200 headers separately) to try and figure out if something's going wrong at the HttpStreamParser/HttpNetworkTransaction layers, or at a higher layer.

Another possibility is that socket reuse is causing some issues, so you could also try having your server send "Connection: Close" with each set of headers.

[Matt Menke]

chromium-dev -> bcc

[Bence Béky]

FYI there's a bug already filed for this which is currently Available: https://crbug.com/671310.  It is particularly interesting because many people outside Chrome commented on it and on https://crbug.com/662197 and https://crbug.com/669820.

On Fri, Jul 21, 2017 at 3:47 AM, Hoang Tran <hoang...@uclouvain.be> wrote: