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 modified Go stdlib codebase that removes
this conditional block: https://golang.org/src/net/http/server.go#L1562
. If you do this, I suggest also filing a bug against Go to evaluate
whether "don't do automatic Continue support" should be added as a Server
- Stick the Go web servers behind a non-Go proxy layer (e.g. nginx) that
strips out the "Expect: 100-continue" header before forwarding to the Go
server. Run one nginx per Go server, on the same machines (or in the same
Kubernetes pods if using GKE), so that the system properties look the same
from the POV of the upstream load-balancer (same number of backends, same
- Wait for GCE to support 100-Continue. Given that 100-Continue is
almost non-existent on the web, personally I wouldn't hold my breath, I
suspect it's a low-priority item.
- You say your clients can't be modified... Can't they? I've never heard
of browsers using 100-Continue unprompted, so if it is just
chrome/firefox/IE, what are you doing that's causing them to use
100-Continue? Or are they some other client software like Mercurial?
On Fri, Sep 16, 2016 at 10:00 AM, Ian Rose <ianros...@gmail.com> wrote:
> 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 . From
> my experiments, it appears that it isn't actually the request header that
> causes the problem, but instead is the server's "100 Continue" response
> that the load balancer dies on. Specifically, the load balancer responds
> with a 502 to the client.
> Any suggestions on how to deal with this? We don't control our clients
> (they are just "browsers across the internet") so solving things on that
> side isn't possible. After digging through the net/http code a bit, my
> best thought is to hijack the connection, which (I think) will prevent a
> "100 Continue" status from being sent. I'm concerned, however, that this
> won't work in all cases - for example http2 connections are not hijackable (
> Is there a better path forward?
>  https://code.google.com/p/google-compute-engine/issues/detail?id=298
> (also see "notes and restrictions" here: https://cloud.google.
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.