Invalid HTTP_IF_NONE_MATCH request header

[Etienne Robillard]

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: 
https://stackoverflow.com/questions/15900548/why-browser-does-not-send-if-none-match-header

Cheers,

Etienne

-- 
Etienne Robillard
tkadm30 at yandex.com
http://www.isotopesoftware.ca/