Invalid HTTP_IF_NONE_MATCH request header

Etienne Robillard tkadm30 at
Thu Jun 15 23:39:26 UTC 2017

Le 2017-06-15 à 19:02, Francis Daly a écrit :
> On Thu, Jun 15, 2017 at 06:29:44PM -0400, Etienne Robillard wrote:
>> Le 2017-06-15 à 18:09, Francis Daly a écrit :
> Hi there,
>>> What request do you make?
>> GET http://localhost/
> Ok.
>>> Which location{} is used to handle that request?
>> location /
> Ok. What file-on-the-filesystem is the file you want your fastcgi server
> to process for this request? I don't see a "fastcgi_index" directive;
> maybe that does not matter in your system.
>>> You appear to do something with HTTP_IF_NONE_MATCH in "location /"
>>> but not in "location /wiki".
>> The /wiki location is handled by a separate fastcgi script.
> Ok.
>>>> 1. Any suggestions why the value of HTTP_IF_NONE_MATCH is not
>>>> defined in nginx ?
>>> Why, specifically, do you think that it is not defined?
>> Firefox omits to add this request header
> There's your answer, then. If the client does not include a header in
> the http request to nginx, nginx will not include the matching param
> in the fastcgi request to the fastcgi server.
>> because I suspect the ETag
>> header was missing from the initial request.
> If that is the reason, then that's the thing to fix. I'm not exactly
> sure what you mean by "the initial request"; but if the client does not
> send something to nginx, nginx cannot do much with it.
>>>> 2. Why is the python script working with wsgiref but not in nginx ?
>>> nginx doesn't "do" python. It does (in this case) fastcgi. Perhaps that
>>> is relevant to the question?
>> I always thought that a python script running under wsgiref is
>> expected to work in fastcgi
>> as-is, without the need to modify nginx configuration.
> Maybe it does. wsgi and fastcgi are different words. I wouldn't assume
> that they are interchangeable, without testing.
> If you can identify exactly what is happening, and what should be
> happening, then you have a chance to identify which specific part
> is failing.
>  From what you have written so far, the problem is with the client not
> making the request that you want.
> Note that the nginx config lines that start with "fastcgi_param HTTP_"
> should not be necessary. I would not be surprised if having them present
> breaks things, but I have not tested for that.
> Cheers,
> 	f
Thanks for your comments, Francis and Valentin.

The problem was with gzip. Disabling gzip allowed the fastcgi script to 
pass the Etag header to the client. :)

See this:



Etienne Robillard
tkadm30 at

More information about the nginx mailing list