Re: 103 Early Hints

Hi Lucas,

2024年9月26日(木) 3:17 Lucas Pardue <lucaspardue.24.7@gmail.com>:

> Hey Glenn
>
> On Wed, Sep 25, 2024, at 03:44, Glenn Strauss wrote:
>
> Lucas wrote:
> > There was also some chatter about highlighting deployment considerations
> about HTTP versions (i.e. it's fine for H2/3 but experience has shown that
> H1 can be problematic). I tend to agree with that. But I'm not sure the
> best sort of text to capture it, do we have any other examples of such a
> consideration?
>
> There is a note in RFC8297 Security Considerations section:
> https://www.rfc-editor.org/rfc/rfc8297.html#section-3
> Lucas, is there more that you would like to add?
>
>
> I had forgotten about that note, so thanks for the pointer! I wonder of
> others have forgotten too.
>
> I'm not 100% sure what additional text might be good but to throw some
> opinions out...
>
> The RFC text says
>
>    Some clients might have issues handling a 103 (Early Hints) response,
>    because informational responses are rarely used in reply to requests
>    not including an Expect header field ([RFC7231], Section 5.1.1).
>
>    In particular, an HTTP/1.1 client that mishandles an informational
>    response as a final response is likely to consider all responses to
>    the succeeding requests sent over the same connection to be part of
>    the final response.  Such behavior might constitute a cross-origin
>    information disclosure vulnerability in case the client multiplexes
>    requests to different origins onto a single persistent connection.
>
>    Therefore, a server might refrain from sending 103 (Early Hints)
>    responses over HTTP/1.1 unless the client is known to handle
>    informational responses correctly.
>
>    HTTP/2 clients are less likely to suffer from incorrect framing since
>    handling of the response header fields does not affect how the end of
>    the response body is determined.
>
>
> I think what this _might_ be overlooking is that the server might think it
> understands the client capabilities but that failures can happen when
> expectations fail. That could even happen when using HTTP/2 or HTTP/3
> (although evidence suggests that HTTP/1.x client are particularly
> problematic for 1xx support *and* they migh trigger a security problem.
>
> The failure cases I've seen ocurred with intermediaries. Even if we tried
> to UA sniff, there could be some proxy in the middle that is passing
> through indicators and we can't detect it. I've also seen the opposite,
> where an H2 proxy client spoke to an upstream CDN that emitted early hints
> and triggered a bug in the non-final response handling of the library (that
> bug was fixed pretty quick though and is no longer a problem).
>
> So as I write this, I'm looking at RFC 8297 and it doesn't really have
> much to say about intermediaries. Section 1 states:
>
> > The informational response can also be used by an
>    origin server to trigger HTTP/2 server push at a caching
>    intermediary.
>
> Not sure that's something we want to include when promoting from
> experimental?
>
> Perhaps intermediares are an area where more deployment experience could
> be captured, in addition to the concrete security considerations already
> present.
>
> Finally, the treatment in this document on non-final responses that are
> not the Expect: 100-continue was unique in 2017 when 103 was forging
> ground. However, we now have things like resumable uploads that are using
> 104. Maybe there'll be some more in future. The considerations about when
> its safe./suitable to emit non-100 non-final responses probably applies
> equally to them all. So perhaps we should be thinking of extracting out the
> common bits into a standalone document. I appreciate that's more upfront
> work but might make it easier to make more robust HTTP extensions in the
> longer run.
>

Yeah, assuming that the concern is about buggy HTTP/1.1 clients somewhere
downstream, it might make sense for intermediaries that transcode H2 or H3
to HTTP/1.1 to drop all advisory 1xx status codes.

But is that the advice we want to give?

As Roy argues, informational response is part of HTTP. And if we are to see
more applications using 1xx codes (some might need them to work, rather
than 103 being a pure optimization), I would be saddened if we have to work
on writing documents where 1xx should not be used.


> Cheers
> Lucas
>
>
> I support advancing RFC 8297 from Experimental to Proposed Standard.
>
> Since lighttpd 1.4.72, 103 Early Hints is employed by the lighttpd
> mod_dirlisting application when generating listings of large directories
> and when a separate link is configured for CSS or JS of the resulting
> page.  In that scenario, lighttpd mod_dirlisting sends 103 Early Hints,
> but only for HTTP/2 and later; not for HTTP/1.x.
>
> Cheers, Glenn
>
> On Wed, Sep 25, 2024 at 01:40:12AM +0100, Lucas Pardue wrote:
> > Hey,
> >
> > On Wed, Sep 25, 2024, at 00:43, Mark Nottingham wrote:
> > > I'm CC:ing Kazuho because I talked to him about updating 8297 from
> Experimental to Proposed Standard at a recent IETF.*
> > >
> > > Given the discussion below and responses to it (which I'd characterise
> as supportive), is anyone willing to submit a draft for the WG to consider
> here? Otherwise, we can request that the IESG update the status of the RFC
> without a draft.
> >
> > My initial email proposed a few things. To clarify, my interpretation of
> the thread was that there was some support for changing it from
> experimental.
> >
> > However, there was not support for adding a new client ssignal.which is
> fine by me.
> >
> > There was also some chatter about highlighting deployment considerations
> about HTTP versions (i.e. it's fine for H2/3 but experience has shown that
> H1 can be problematic). I tend to agree with that. But I'm not sure the
> best sort of text to capture it, do we have any other examples of such a
> consideration?
> >
> > Am happy to help things but the natural pen holder would IMO be Kazuho
> still.
> >
> > Cheers
> > Lucas
> >
> > >
> > > Cheers,
> > >
> > >
> > > * No, I don't remember which one.
> > >
> > >
> > > > On 10 Jun 2023, at 12:09 pm, Lucas Pardue <
> lucaspardue.24.7@gmail.com> wrote:
> > > >
> > > > Hi folks,
> > > >
> > > > RFC 8297, defining 103 Early Hints was published in 2017. It's been
> a bit of a sleeper hit, in the last 18 months or so we've seen uptake and
> deployment on client and server sides.
> > > >
> > > > As is natural, we've been gaining experience through deployment.
> Helping to identify the areas with Early Hints helps, and areas where there
> might be some possible tweaks. One example is that it isn't always useful
> to emit a 103 Early Hint in response to every request that is received,
> because the client's processing context would ignore it.
> > > >
> > > > Client Hints (RFC 8942) has some text that deals with considerations
> we are now learning about Early Hints. For instance, a server could emit an
> Accept-CH header, and Section 5 of RFC 8942 describes considerations for
> the cost of sending Client Hints.
> > > >
> > > > After some chatter on Twitter the past week, a few different people
> suggested that something like an Accept-EH request header field might be
> useful to help clients to indicate when Early Hints are useful or not. If
> we made this a list of field names, it could allow some tailoring of the
> emission and content of the hints.
> > > >
> > > > My thinking was maybe its time to upgrade Early Hints from
> experimental and roll in some of the learnings / proposals into the update
> document.
> > > >
> > > > Thoughts?
> > > >
> > > > Cheers,
> > > > Lucas
> > >
> > > --
> > > Mark Nottingham   https://www.mnot.net/
> > >
> > >
> > >
>
>
>
>

-- 
Kazuho Oku