[go-nuts] How to deal with 'Expect:100-continue'

2020-03-23 Thread Shigeru Ota
I want to return "too large body" response whenever a request's body is larger than setting. However, when the request has "Expect" header, the connection may be reset if the requestbody is not read to end. Then, I added check function. The function check 'Content-Length' and return error

Re: [go-nuts] How to deal with "Expect: 100-continue" *without* sending a 100 status

2016-10-29 Thread jrwren
Sorry to resurrect a month old thread, but I just implemented bullet #2 with this patch. I need to disable the automatic 100-continue behavior so that my handler can reply with a 40X status before the client read the 100-contine and starts sending data. On Saturday, September 17, 2016 at

Re: [go-nuts] How to deal with "Expect: 100-continue" *without* sending a 100 status

2016-09-17 Thread Ian Rose
Thanks Dave - all good suggestions! > Use a GCE Network LB instead of HTTP LB. I'm hoping to avoid using a network LB since we are operating over https so that means we'll have to terminate SSL ourselves (which means distributing our certs to each backend instance). Using an http(s) LB means we

Re: [go-nuts] How to deal with "Expect: 100-continue" *without* sending a 100 status

2016-09-16 Thread David Anderson
Tricky one. A couple of options spring to mind, none of them amazingly good: - Use a GCE Network LB instead of HTTP LB. You can bring the TCP sessions straight to your web servers, with load-balancing done per-TCP-session rather than per-HTTP-request. - Build your web server using a

[go-nuts] How to deal with "Expect: 100-continue" *without* sending a 100 status

2016-09-16 Thread Ian Rose
Howdy, I'm currently running a group of Go web servers behind an HTTP(s) load balancer on Google Compute Engine. Unfortunately I have learned that GCE load balancers do not support the "Expect: 100-continue" header [1]. From my experiments, it appears that it isn't actually the request