Thank you Masakazu. That's good feedback. I didn't think of how the empty reason phrase is a strong hint of what is going on in the backend.
As I investigated things further, it turns out we already have an implementation of a default reason phrase. I'm working on applying the use of it to this situation via PR: https://github.com/apache/trafficserver/pull/9615 I have some details to work out, as evidenced by some failing AuTests, but that direction looks promising. I'll continue working on that patch this coming week. Thanks, Brian On Sat, Apr 15, 2023 at 1:41 AM Masakazu Kitajo <mas...@apache.org> wrote: > Let's refer to the latest specs. > https://www.rfc-editor.org/rfc/rfc9112.html#name-status-line > > The reason-phrase is optional, but the SP between status-code and > reason-phrase is not. The spec clearly states it. > > status-line = HTTP-version SP status-code SP [ reason-phrase ] > > > A server MUST send the space that separates the status-code from the > reason-phrase even when the reason-phrase is absent (i.e., the status-line > would end with the space). > > We need to check whether the space is sent. > > > Another thing we may want to consider is security. A couple of attacks that > use protocol conversion between H1 and H2 were found in the past several > years. Empty reason phrase implies H2 was used on the server/origin side, > and it can be used as a hint to find a target. > > > I'd say we should send reason-phrase if there is a good default phrase for > a status code. > > Thanks, > Masakazu > > > On Fri, Apr 14, 2023 at 11:02 AM Brian Neradt <brian.ner...@gmail.com> > wrote: > > > dev@trafficserver.apache.org: > > > > The current master (10.x) branch has HTTP/2 to origin support. The HTTP/2 > > protocol has officially removed reason phrases from the RFC: > > https://www.rfc-editor.org/rfc/rfc7540.html#section-8.1.2 > > > > HTTP/2 does not define a way to carry the version or reason phrase that > is > > > included in an HTTP/1.1 status line. > > > > > > I noticed recently that in the situation where the client talks HTTP/1.1 > to > > ATS while ATS has negotiated HTTP/2 to the origin, ATS faithfully proxies > > an "empty" reason phrase from the HTTP/2 origin to the HTTP/1 client. Per > > the HTTP/1 RFC, an empty reason phrase is technically valid: > > https://www.rfc-editor.org/rfc/rfc7230#section-3.1.2 > > > > A client SHOULD ignore the reason-phrase content. > > > reason-phrase = *( HTAB / SP / VCHAR / obs-text ) > > > > > > However in discussing this with some other devs, some raise reasonable > > concerns about clients not handling the empty phrase correctly. > > > > So I invite feedback. Which of the following should ATS do: > > > > - ATS remain as is and return an empty reason string. The logic being > > that this is the most technically correct direction: there is no > reason > > phrase from the server, an empty reason phrase is valid HTTP/1.x, and > - > > since there is no hard and fast specified mapping of reason strings to > > status codes - there's no deterministic way to conjecture what reason > > phrase any particular server would use. > > - Or, to anticipate clients that will have issues parsing an empty > > reason phrase, we map default reason phrases to response status codes. > > We > > can use https://www.rfc-editor.org/rfc/rfc7231#section-6.1 and/or > > > > > https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml > > for this default mapping. > > > > Thanks, > > Brian > > > > -- > > "Come to Me, all who are weary and heavy-laden, and I will > > give you rest. Take My yoke upon you and learn from Me, for > > I am gentle and humble in heart, and you will find rest for > > your souls. For My yoke is easy and My burden is light." > > > > ~ Matthew 11:28-30 > > > -- "Come to Me, all who are weary and heavy-laden, and I will give you rest. Take My yoke upon you and learn from Me, for I am gentle and humble in heart, and you will find rest for your souls. For My yoke is easy and My burden is light." ~ Matthew 11:28-30
