1

I had to relocate our local service to another ip address and added a HAproxy to handle the request. My problem is that my client tries to send requests using Transfer-encoding: chunked. If I use this settings then I get error 411. HAProxy works in SSL termination mode. If there is no proxy used at client side (between JAX-WS client and HAproxy) then the connection works fine but if there is a proxy between them then it fails with error 411. I have two different clients. One of them uses McAfee Web Gateway the other one uses Squid 2.7. Both proxies require authentication. I tried different versions of HAProxy, Tomcat, JRE without success.

The scenario looks like this.

**Old config:**

JAX-WS client request 
   |
( Proxy ) 
   |
router with public ip (port 8442 for http and 8443 for https)
   |
NATed JAX-WS endpoint running in Tomcat container 192.168.1.242:8080

**New config:**

  JAX-WS client request 
       |
(Proxy with or without authentication)
       |
  Router with public ip 
       | 
       | 
|----------- IPSec tunnel-----------------------------------------------------|
| 192.168.91.246                  192.168.1.242:8080                          |
| HAProxy (NATed) --------------- JAX-WS endpoint running in tomcat container |
|-----------------------------------------------------------------------------|


**A failed POST request:**

POST /ddc/ddcService HTTP/1.1
Accept: text/xml, multipart/related
Authorization: Basic xxxxxxxxxxxxxxxxxxxxxxx=
Content-Type: multipart/related;start="<rootpart*b440d52f-dee1-4735-9ff5-6093fa9d774b@example.jaxws.sun.com>";type="application/xop+xml";boundary="uuid:b440d52f-dee1-4735-9ff5-6093fa9d774b";start-info="text/xml"
SOAPAction: ""
User-Agent: JAX-WS RI 2.2.6-1b01  svn-revision#13094
Host: ddc.zzzz.com
Proxy-Connection: keep-alive
Transfer-Encoding: chunked



**HAproxy config:**

global
    log /dev/log    local0
    log /dev/log    local1 notice info
    debug
    chroot /var/lib/haproxy
    stats socket /run/haproxy/admin.sock mode 660 level admin
    stats timeout 30s
    stats bind-process 7
    user haproxy
    group haproxy
    daemon
    nbproc 7
    tune.bufsize 32768
    tune.ssl.default-dh-param 2048
    ssl-default-bind-ciphers kEECDH+aRSA+AES:kRSA+AES:+AES256:RC4-SHA:!kEDH:!LOW:!EXP:!MD5:!aNULL:!eNULL
    ssl-default-bind-options no-sslv3

defaults
    log global
    mode    http
    bind-process 3
    option  httplog
    option  dontlognull
    timeout connect 5000
    timeout client  50000
    timeout server  50000
    option  httpclose
    errorfile 400 /etc/haproxy/errors/400.http
    errorfile 403 /etc/haproxy/errors/403.http
    errorfile 408 /etc/haproxy/errors/408.http
    errorfile 500 /etc/haproxy/errors/500.http
    errorfile 502 /etc/haproxy/errors/502.http
    errorfile 503 /etc/haproxy/errors/503.http
    errorfile 504 /etc/haproxy/errors/504.http
    option forwardfor except 127.0.0.1
    option tcp-smart-connect


frontend incoming

    bind *:8080 name http
    bind *:4443 ssl  crt /etc/letsencrypt/live/ddc.xxx.com/fullchain.pem.bundle 
    option forwardfor header X-Real-IP
    use_backend  ddc if ddc

backend ddc
    option forwardfor
    mode http
    http-request set-header X-Forwarded-Port %[dst_port]
    http-request replace-header Host ^(.*?)(:[0-9]+)?$ \1
    server ddc 192.168.1.242:8080 check port 8080
Eugène Adell
  • 3,089
  • 2
  • 18
  • 34
sfeher
  • 51
  • 4
  • Maybe try to buffer the request, with `option http-buffer-request` . However it doesn't explain the behaviour change when removing the client's proxy, which by the way is almost transparent as you're using SSL (client sends a CONNECT, the proxy opens a connection to the haproxy, the handshake takes place between the client and the haproxy) – Eugène Adell Sep 10 '18 at 21:33
  • I have tried it but did not help. – sfeher Sep 11 '18 at 09:04
  • It's maybe out of context but at a client who does not use proxy my host filtered out as possible buffer overflow attacker. With or without option http-buffer-request. – sfeher Sep 11 '18 at 09:11
  • HTTP allows [resumable uploads](http://www.grid.net.ru/nginx/resumable_uploads.en.html) but we don't know if your server (and proxies) will allow it, and if your client libraries support it. Not an easy problem. – Eugène Adell Sep 11 '18 at 19:26
  • This solution worked fine without haproxy for years. I suspect the problem lies around haproxy. – sfeher Sep 12 '18 at 06:21
  • I understand, but from what I read, chunked requests are not allowed by haproxy because it is afraid of slow DOS attacks (like a client sending chunks of one byte, and never closing the request). I only see workarounds to your problem (layer 4 load-balancing without SSL offloading, moving to resumable uploads,..), no exact answer to your question. Hence, commenting, and not posting an answer. – Eugène Adell Sep 12 '18 at 07:13
  • 1
    Thank you anyway. It seems I must drop the chunked method to get it fixed. I will check if any side effect occures but so far it works fine if I don't use chunked mode. – sfeher Sep 14 '18 at 12:55

0 Answers0