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
