Since proxy_pass by default uses HTTP 1.0 shouldn't it also clear the
Connection header by default?
This causes major problems for the unsuspecting reverse proxy that
encounters a .NET system.net.WebClient request. WebClient automatically
sends Connection: keep-alive even for a HTTP 1.1 request. S
I have found the point where my rules break,
I've had the following location on top, to enable browser caching for
images, for one month:
#images give caching response for 1 month, browser will request after
this period of time again
location ~* \.(png|jpg|jpeg|gif)$ {
expires 1m;
log_not_fo
Hello,
On Fri, Jun 14, 2013 at 4:35 AM, wrote:
> Am 13.06.2013 19:35, schrieb B.R.:
>
>> What is the observed behavior?
>>
>
> The parameters are not given corectly to the php script, delivering the
> picture.
>
What
does the script receive ? Details!
> What do show your logs?
>>
>
> As
Hello,
nginx 1.4.1 is truncating proxy output for large files.
*** Steps to reproduce ***
nginx.conf:
location ^~ /download/ {
proxy_passhttp://localhost:9000;
proxy_set_header Host $host;
}
The back end is a very simple servlet that copies a static file to t
Thanks for the Detailed Information :-)
I have still problems with this role:
Client sends the first part of the urls, server rewrites it, and php
delivers the picture.
I tried to escape \ and dots, but this does not help.
Server gives back a 404.
Then I activated the error_log with level not
On Fri, 14 Jun 2013 09:58:12 +0200, mailinglis...@simonhoenscheid.de
wrote:
> Both solutions look interesting, I will have a look on it.
We use been successfully the "return no content=204" opiton:
location = /favicon.ico { access_log off; log_not_found off; expires
30d; try_files /sites/$server
Am 13.06.2013 19:35, schrieb B.R.:
What is the observed behavior?
The parameters are not given corectly to the php script, delivering the
picture.
What do show your logs?
As expected there ist a 404 in the belonging access log. I activated the
rewrite_log but there is no output in the er
Both solutions look interesting, I will have a look on it.
Am 13.06.2013 23:01, schrieb B.R.:
On Thu, Jun 13, 2013 at 4:51 PM, Jonathan Matthews
wrote:
On 13 June 2013 09:38, wrote:
[snip]
RewriteRule ^favicon.ico$ - [R=404,L]
location /(^favicon)/(.*.(ico)) {
return 404;
Don't do that. You
