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 >
