Thanks for the warning! I have to admit i was a little surprised to learn
that, arguably, the two major browsers don't implement 100-continue and have
no plan to do so. I know our scenario is far from typical but POST uploads
are surely widespread.
Thanks to all for your help on this, the support
On Wednesday 27 September 2017 06:57:00 garyc wrote:
[..]
> We can live with a 2 stage process for now, may look to move to http 2 for
> other reasons in the future, we can address this properly then.
>
[..]
Well, Chrome behavior with HTTP/2 isn't better.
Here's a workaround that we had to add i
Thanks, understood.
Got a bit excited when I realized our client wasn't sending the 'Expect:
100-continue' header in our POST but as you have pointed out even with this
header Chrome and Firefox do not stop sending the body.
Posted at Nginx Forum:
https://forum.nginx.org/read.php?2,276512,27657
Hello!
On Wed, Sep 27, 2017 at 06:57:00AM -0400, garyc wrote:
> Looks like support for 100 Continue:
>
> https://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8.2.3
>
> may have covered our scenario, I found an old ticket on this
>
> https://trac.nginx.org/nginx/ticket/493#no1
Support for
Looks like support for 100 Continue:
https://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8.2.3
may have covered our scenario, I found an old ticket on this
https://trac.nginx.org/nginx/ticket/493#no1
I guess there is no intention to support this in a future release?
We can live with a 2
I had a look around for expected behavior during large http 1.x POST
requests, it looks like the standards suggest that browsers should monitor
for 413 responses and terminate the body transmission but they don't:
https://stackoverflow.com/questions/18367824/how-to-cancel-http-upload-from-data-eve
Ok, thanks, I will look into tcpdump. In your opinion, in principle, is what
i am attempting feasible?
>In the second case, 30 seconds after the response was sent by nginx, the
>request body still wasn't received and nginx had nothing to do than just
>close the connection.
This suggests to me tha
On Tuesday 26 September 2017 05:07:25 garyc wrote:
[..]
>
> indicate that the request was unacknowledged by the client hence the http
> request is closed along with the connection:
>
> > 2017/09/21 12:09:31 [debug] 22090#0: *1 close http connection: 3
>
> and it is marked as non re-usable?
>
>
Hello, thanks for explaining, can I ask, in the 5MB scenario (client
accepted 413 response) the logs show:
2017/09/21 12:06:41 [debug] 21560#0: *1 http run request:
"/pcapLowDiskSpace.html?"
2017/09/21 12:06:41 [debug] 21560#0: *1 http read discarded body
2017/09/21 12:06:41 [debug] 21560#0: *1 re
On Monday 25 September 2017 22:14:04 Valentin V. Bartenev wrote:
> On Monday 25 September 2017 07:17:08 garyc wrote:
> > Apologies, I posted this issue to the wrong list (php-fpm), the link is:
> >
> > > https://forum.nginx.org/read.php?3,276451,276475#msg-276475
> >
> > It has debug log file ext
On Monday 25 September 2017 07:17:08 garyc wrote:
> Apologies, I posted this issue to the wrong list (php-fpm), the link is:
>
> > https://forum.nginx.org/read.php?3,276451,276475#msg-276475
>
> It has debug log file extracts that seem to suggest the location redirect to
> a static error page is
Apologies, I posted this issue to the wrong list (php-fpm), the link is:
> https://forum.nginx.org/read.php?3,276451,276475#msg-276475
It has debug log file extracts that seem to suggest the location redirect to
a static error page is attempted but doesn't resolve.
Many thanks
Posted at Nginx F
12 matches
Mail list logo
