Thank you for your responses!
On Tue, Aug 20, 2013 at 2:44 PM, Francis Daly wrote:
> On Mon, Aug 19, 2013 at 02:53:36PM -0700, Paul N. Pace wrote:
>
> Hi there,
>
>> I am trying to set up a conf file for Piwik installations and I'm
>> hoping a second set of of eyes can help:
>
> In nginx one requ
Hello !
I run nginx as a reverse proxy and send requests to an upstream server,
the problem is according to my logs sometimes i start seeing this:
[499] [-] [0] [11602] [xx.126.55.81] [GET /weblogin/ HTTP/1.1]
or
[504] [-] [0] [11602] [xx.126.55.81] [GET /weblogin/ HTTP/1.1]
The first field
On Tue, Aug 20, 2013 at 5:12 PM, rmalayter wrote:
> No, the conclusion is: don't echo back values supplied by the requester as
> trusted in your *application* code. This is the most basic of
> anti-injection
> protections. BREACH is the result of an application-layer problem, and
> needs
> to be
On Mon, Aug 19, 2013 at 02:53:36PM -0700, Paul N. Pace wrote:
Hi there,
> I am trying to set up a conf file for Piwik installations and I'm
> hoping a second set of of eyes can help:
In nginx one request is handled in one location. The rules for selecting
the location are at http://nginx.org/r/l
B.R. Wrote:
> BREACH attacks the fact that compressed HTTP content encrypted with
> SSL
> makes it easy to guess a known existing header field from the request
> that
> is repeated in the (encrypted) answer looking at the size of the body.
> BEAST conclusion is: don't use HTTP compression underneat
H
i
>
> After a 60 seconds timer was fired and client connection was
>
> closed as timed out.
>
> Yeah. That's what I feared. But the connection was definitely still
> open and data was being transferred.
You are still testing through your 2G GSM connection, right?
How can you be sure that this c
Hello,
I am writing an nginx plugin and I am trying to send sub-requests to an
upstream server.
I am aware of the ngx_http_subrequest function but I didn't succeed to use
it in my case and I am not sure it is what I need.
In my use case, I have a structure in shared memory. This structure must
le
Hello!
On Tue, Aug 20, 2013 at 03:14:20PM +0200, Philip Hofstetter wrote:
> Hello!
>
> On Tue, Aug 20, 2013 at 1:26 PM, Maxim Dounin wrote:
>
> > 2013/08/20 09:34:31 [debug] 1692#0: *1101651 http upstream process non
> > buffered downstream
> > 2013/08/20 09:34:31 [info] 1692#0: *1101651 clie
Hello!
On Tue, Aug 20, 2013 at 1:26 PM, Maxim Dounin wrote:
> 2013/08/20 09:34:31 [debug] 1692#0: *1101651 http upstream process non
> buffered downstream
> 2013/08/20 09:34:31 [info] 1692#0: *1101651 client timed out (110: Connection
> timed out) while sending to client, client: 80.219.149.11
Hello!
On Tue, Aug 20, 2013 at 09:49:32AM +0200, Philip Hofstetter wrote:
> Ok. I have three debug logs now:
>
> http://www.gnegg.ch/debug-cancel.log
> is the first log I created where I quit curl once nginx has logged a
> 200 status with a truncated length to the access log (how can it log
> su
Ok. I have three debug logs now:
http://www.gnegg.ch/debug-cancel.log
is the first log I created where I quit curl once nginx has logged a
200 status with a truncated length to the access log (how can it log
success while it's still transmitting data?)
http://www.gnegg.ch/debug-full.log
is the sa
The last debug log I sent is not showing the full picture. In this
case, I was aborting the curl command once nginx has logged an
incomplete response (status=200 but too short length) to access.log,
but while it was still transferring data (how's that even possible)?
Hence the "connection reset by
Hi,
On Mon, Aug 19, 2013 at 7:05 PM, Lukas Tribus wrote:
> Looks like there is some timeout at 600 seconds (Time Spent: 0:09:58)? Any
> match
> in the haproxy or nginx configurations?
That's consistent with what nginx is logging to the error log. But it
doesn't make sense as there is data bei
13 matches
Mail list logo
