Hello! On Thu, Aug 31, 2023 at 03:45:06PM +0400, Sergey Kandaurov wrote:
> > On 31 Aug 2023, at 14:28, Maxim Dounin <mdou...@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 <mdou...@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 <kapo...@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
