Problems with HTTP/2

[Valentin V. Bartenev]

On Tuesday 29 September 2015 13:34:46 Aapo Talvensaari wrote:
> On 29 September 2015 at 12:25, Francis Daly <francis at daoine.org> wrote:
> > On Tue, Sep 29, 2015 at 01:06:50AM +0300, Aapo Talvensaari wrote:
> > > It just sets the status code. It is normal PHP 5.3 code [1]. I might need
> > > to compile nginx by hand to get more debug info.
> >
> > For what it's worth:
> >
> > when I test with a php 5.1.6 and a php 5.3.3,
> >
> >   header(':', true, 403);
> >
> > Using
> >
> >   header("HTTP/1.1 403 Whatever");
> >
> > sets the status code and does not add the dubious header.
> 
> 
> Thanks. I know this is not probably a best way to set it (and in this case
> I can change it, but it seems like this may cause some problems with user code.
> See, the browsers accept it, the Nginx HTTP accepts it, Nginx HTTPS accepts
> it, and even Nginx SPDY accepts it. Only Nginx HTTP/2 will not accept it.

The error that you have seen isn't from NGINX, it's generated by browser.
The behavior of NGINX is consistent across all protocols, but the reaction
of specific browser, that you have tested, seems not.

> And by accepting I mean, browsers and other Nginx protocols give the correct
> status code as well.

It's not about the status code.  Note, that the function you are calling in PHP
does two things: 1. sets the status code; 2. adds invalid header.

The 1 and 2 aren't related to each other.
 
> 
> Thanks for debugging this furher. I think everyone now has the knowledge of
> what is going on.
> 
> Is this a bug or a feature? 

Yes, it's a bug. But it's in the application that generates invalid response.
The result of such invalid response is undefined - may work or may not, depending
on client's behavior.  NGINX tolerates it, some browsers do not.

> Because it might break user code running on
> Nginx, I might call it a bug.

The code was already broken, it was a coincidence that it worked.

  wbr, Valentin V. Bartenev