status-line trailing SP is missing ?

[Maxim Dounin]

Hello!

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

> > On 31 Aug 2023, at 14:28, Maxim Dounin <mdounin at 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 at 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 at 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/