Hello!

On Thu, Aug 31, 2023 at 03:45:06PM +0400, Sergey Kandaurov wrote:

> > On 31 Aug 2023, at 14:28, Maxim Dounin <mdounin@mdounin.ru> wrote:
> >
> > Hello!
> >
> > On Wed, Aug 30, 2023 at 04:20:15PM +0400, Sergey Kandaurov wrote:
> >
> >>> On 29 Aug 2023, at 08:33, Maxim Dounin <mdounin@mdounin.ru> wrote:
> >>>
> >>> On Mon, Aug 28, 2023 at 08:59:28PM +0400, Sergey Kandaurov wrote:
> >>>
> >>>>> On 26 Aug 2023, at 18:21, Jérémy Lal <kapouer@melix.org> wrote:
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> https://bugs.debian.org/1050571
> >>>>> reports that the Status line doesn't always end with space, which seems contradictory to RFC9112 which states:
> >>>>> "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)."
> >>>>>
> >>>>> Is it a documented nginx 1.24.0 behavior ?
> >>>>>
> >>>>
> >>>> Note that the response line with empty reason phrase
> >>>> is properly generated since nginx 1.5.6.
> >>>> The exception remains is proxying FastCGI responses
> >>>> as there is no distinguished response line in CGI syntax.
> >>>>
> >>>> The reason is that Status is a CGI header field, and hence
> >>>> it is parsed by a generic routine that cuts trailing spaces.
> >>>> But it can have a trailing space per RFC 3875, section 6.3.3.
> >>>> So it needs a special treatment to preserve SP before empty reason
> >>>> phrase. The below patch should help; although it doesn't look
> >>>> efficient and can be polished, I think this is quite enough for
> >>>> valid use cases.
> >>>
> >>> I very much doubt that RFC 3875 properly defines whitespace
> >>> handling, see my response to the original report. In this
> >>> particular case, it seems to define a header which cannot be
> >>> correctly parsed if reason-phrase is empty.
> >>>
> >>
> >> Yes, it is quite dubious how this can be parsed correctly.
> >> Although it is valid to have a trailing space in Status,
> >> this contradicts to header field value syntax per RFC 3875:
> >> field-content = *( token | separator | quoted-string )
> >
> > Note that field-value syntax does no apply to the "Status" header,
> > its syntax is defined separately.
>
> Well, per RFC 3875 BNF, Status is CGI-field, which if generalized
> to other-field, consists of field-content.

Syntax is as follows
(https://datatracker.ietf.org/doc/html/rfc3875#section-6.3):

header-field = CGI-field | other-field
CGI-field = Content-Type | Location | Status
other-field = protocol-field | extension-field
protocol-field = generic-field
extension-field = generic-field
generic-field = field-name ":" [ field-value ] NL

CGI-field and other-field are mutually exclusive variants of
header-field, and there is no generalization.

Generalization was present in the original RFC draft
(https://datatracker.ietf.org/doc/html/draft-robinson-www-interface-00#section-9.2),
but was removed during work on RFC 3875 (in
https://datatracker.ietf.org/doc/html/draft-coar-cgi-v11-03). Not
sure about the reasons, but might be because Status indeed does not
conform to the generic-field syntax, and this was an attempt to
fix it.

Either way, the fact is: RFC 3875 does not correctly specify
whitespace handling, and shouldn't be relied upon.

[...]

--
Maxim Dounin
http://mdounin.ru/
_______________________________________________
nginx mailing list
nginx@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx