Apologies, I did not see your other comment.  I do not have access to the logs 
of the remote server as it is 3rd party.  

On 2/14/17, 11:06 PM, "Cyril Bonté" <[email protected]> wrote:

    Le 15/02/2017 à 00:10, Birdwell, Rob a écrit :
    > Hi Cyril!
    >
    > Responses below:
    >
    > Are you really sure you're making the same request on the application 
side (access logs should give you a hint) ?
    >
    > Positive.  I’m making the curl request directly from the Apache HTTP 
server & HAProxy server.  The details for the HAProxy curl are in the thread 
way down below.  I can share the exact curl command if it helps you (and as 
long as the contents stay between us).  Logs from proxy are directly below:
    
    I'm not talking about the request from the client to haproxy but from 
    haproxy to the application server. In your apache configuration, you 
    have ProxyPass directives that are not reimplemented in the haproxy 
    configuration.
    
    
    > Feb 14 22:52:06 localhost haproxy[22304]: Proxy globalstats started.
    > Feb 14 22:52:06 localhost haproxy[22304]: Proxy www-http started.
    > Feb 14 22:52:06 localhost haproxy[22304]: Proxy www-frontend started.
    > Feb 14 22:52:06 localhost haproxy[22304]: Proxy www-backend started.
    > Feb 14 22:52:10 localhost haproxy[22305]: 34.195.251.10:30874 
[14/Feb/2017:22:52:10.262] www-frontend~ www-backend/lp 67/0/4/6/77 200 158 - - 
---- 1/1/0/1/0 0/0 "POST /chat/request.json?v=1 HTTP/1.1"
    
    Again, I was talking about the access logs of your application server, 
    not the proxy.
    
    I still want to know what happens when calling this url :
    /api/account/61447612/data/request.json?v=1
    instead of
    /data/request.json?v=1
    
    
    >
    >
    >
    >
    >
    > On 2/14/17, 3:28 PM, "Cyril Bonté" <[email protected]> wrote:
    >
    >     Le 14/02/2017 à 22:20, Birdwell, Rob a écrit :
    >     > Thanks for the quick reply Cyril!
    >     >
    >     > You’re correct on both counts; this is a test config & the large 
timeout will definitely not be kept.  For the http-server-close, that was a 
mistake on my part; thank you for noticing that.  I’ve tried the configuration 
both ways (as far as http-send-name-header) & receive the same result.  Happy 
to try any additional suggestions you can provide.  (BTW, I just tried removing 
the http-send-name-header which gave the same results).
    >
    >     Are you really sure you're making the same request on the application
    >     side (access logs should give you a hint) ?
    >
    >     What happens with a curl request on
    >     /api/account/61447612/data/request.json?v=1 through haproxy ? (to
    >     reproduce the ProxyPass directives in apache). Something like :
    >     curl -i --header "Accept:application/json" --header
    >     "Content-Type:application/json" --header "Authorization:<appname>
    >     appKey=<key>" -X POST
    >     https://<frontend_url>/api/account/61447612/data/request.json?v=1
    >     --verbose --data "{\"data\": { \"data\": \"data\", \"maxWaitTime\":
    >     60000 } }" --cacert /etc/haproxy/ssl/<frontend>.pem
    >
    >
    >
    >     >
    >     > On 2/14/17, 1:58 PM, "Cyril Bonté" <[email protected]> wrote:
    >     >
    >     >     Hi Rob,
    >     >
    >     >     Le 14/02/2017 à 20:23, Birdwell, Rob a écrit :
    >     >     > Hello,
    >     >     >
    >     >     > I was curious if someone would be able to assist with return 
codes from HAProxy.  Currently, we are able to receive a 201 for a reverse 
proxy solution from Apache HTTP, but when utilzing HAProxy, only a 200 is 
received utilizing an identical cURL command.  The current HAProxy/Apache HTTP 
& cURL outputs I have are below:
    >     >     >
    >     >     > HAProxy configuration:
    >     >     >
    >     >     > global
    >     >     >
    >     >     >     log         127.0.0.1 local2 debug
    >     >     >
    >     >     >     chroot      /var/lib/haproxy
    >     >     >     pidfile     /var/run/haproxy.pid
    >     >     >     maxconn     100000
    >     >     >     group       root
    >     >     >     daemon
    >     >     >     tune.ssl.default-dh-param 2048
    >     >     >
    >     >     >     stats socket /var/lib/haproxy/stats
    >     >     >
    >     >     >
    >     >     > defaults
    >     >     >     mode                    http
    >     >     >     log                     global
    >     >     >     option                  httplog
    >     >     >     option                  log-separate-errors
    >     >     >     option                  dontlognull
    >     >     >     option                  http-keep-alive
    >     >     >     option                  dontlog-normal
    >     >     >     option                  http-server-close
    >     >
    >     >     Not related to your issue but you have to make a choice : use
    >     >     "http-server-close" or "http-keep-alive", but not both.
    >     >
    >     >     >     option                  redispatch
    >     >     >     option                  contstats
    >     >     >     option                  forwardfor
    >     >     >     timeout http-request    45s
    >     >     >     timeout queue           45s
    >     >     >     timeout connect         45s
    >     >     >     timeout client          45s
    >     >     >     timeout server          45s
    >     >     >     timeout http-keep-alive 45s
    >     >     >     timeout check           45s
    >     >
    >     >     Those timeouts should be better tuned.
    >     >
    >     >     >     http-send-name-header host
    >     >
    >     >     Here, there's something that can be related to what you observe.
    >     >     Are you really sure you want to set a "Host" header on the 
request
    >     >     between haproxy and your backend server ? Note that it also 
appears in
    >     >     www-backend below.
    >     >
    >     >     >     maxconn                 50000
    >     >     >
    >     >     > listen globalstats
    >     >     >     mode http
    >     >     >     bind *:1936
    >     >     >     stats enable
    >     >     >    stats show-desc HAProxy for <frontend_url>
    >     >     >     stats uri /stats
    >     >     >     stats show-legends
    >     >     >     stats show-node
    >     >     >     stats refresh 5s
    >     >     >
    >     >     > frontend www-http
    >     >     >    bind *:80
    >     >     >    reqadd X-Forwarded-Proto:\ http
    >     >     >    default_backend www-backend
    >     >     >
    >     >     > frontend www-frontend
    >     >     >    bind *:443 ssl crt /etc/haproxy/ssl/<frontend>.pem
    >     >     >    mode http
    >     >     >    reqadd X-Forwarded-Proto:\ https
    >     >     >    default_backend www-backend
    >     >     >
    >     >     > backend www-backend
    >     >     >    redirect scheme https if !{ ssl_fc }
    >     >     >    http-send-name-header host
    >     >
    >     >     Same observation here, I'd recommend to make some tests without 
those
    >     >     "http-send-name-header host".
    >     >
    >     >     >    server lp <backend app>:80 check
    >     >     >
    >     >     > Apache config:
    >     >     >
    >     >     > NameVirtualHost *:80
    >     >     > <VirtualHost *:80>
    >     >     >        ServerName <frontend_url>
    >     >     >
    >     >     >        Redirect / https://<backend_app>/api/account/61447612/
    >     >     >
    >     >     >
    >     >     > </VirtualHost>
    >     >     >
    >     >     > NameVirtualHost *:443
    >     >     > <VirtualHost *:443>
    >     >     >        ServerName <frontend_url>
    >     >     >        LogLevel debug
    >     >     >        CustomLog /etc/httpd/logs/ssl_access_log frontoffice
    >     >     >        ErrorLog /etc/httpd/logs/ssl_access_log
    >     >     >
    >     >     >        LimitRequestLine 1000000
    >     >     >        LimitRequestFieldSize 1000000
    >     >     >
    >     >     >        SSLEngine On
    >     >     >        SSLProxyEngine On
    >     >     >
    >     >     >        SSLProxyCheckPeerCN off
    >     >     >        SSLProxyCheckPeerExpire off
    >     >     >
    >     >     >        AllowEncodedSlashes On
    >     >     >        ProxyPreserveHost On
    >     >     >
    >     >     >
    >     >     >        SSLCertificateFile /etc/httpd/ssl/<frontend_url>.pem
    >     >     >        SSLCertificateChainFile 
/etc/httpd/ssl/<frontend_url>.pem
    >     >     >
    >     >     >        RewriteEngine On
    >     >     >
    >     >     >        ProxyPass              /   
https://<backend_app>/api/account/61447612/  retry=2 acquire=3000 timeout=600 
Keepalive=On
    >     >     >        ProxyPassReverse       https://<frontend_url>/   
https://<backend_app>/api/account/61447612/
    >     >     >        ProxyPassReverseCookiePath   
https://<backend_app>/api/account/61447612/ https://<frontend_url>/
    >     >     >
    >     >     > </VirtualHost>
    >     >     >
    >     >     >
    >     >     >
    >     >     >
    >     >     > Curl command is as follows:
    >     >     >
    >     >     > curl -i --header "Accept:application/json" --header 
"Content-Type:application/json" --header "Authorization:<appname> appKey=<key>" 
-X POST https://<frontend_url>/data/request.json?v=1  --verbose --data 
"{\"data\": { \"data\": \"data\", \"maxWaitTime\": 60000 } }" --cacert 
/etc/haproxy/ssl/<frontend>.pem
    >     >     >
    >     >     >
    >     >     >
    >     >     > Curl output from HAProxy:
    >     >     >
    >     >     >
    >     >     > …
    >     >     >
    >     >     >> POST /data/request.json?v=1 HTTP/1.1
    >     >     >> Host: <frontend_app>
    >     >     >> User-Agent: curl/7.47.1
    >     >     >> Accept:application/json
    >     >     >> Content-Type:application/json
    >     >     >> Authorization:<appname> appKey=<key>
    >     >     >> Content-Length: 65
    >     >     >>
    >     >     > * upload completely sent off: 65 out of 65 bytes
    >     >     > < HTTP/1.1 200 OK
    >     >     > < Server: WS
    >     >     > < P3P: CP="NON BUS INT NAV COM ADM CON CUR IVA IVD OTP PSA 
PSD TEL SAM"
    >     >     > < Date: Tue, 14 Feb 2017 07:49:09 GMT
    >     >     > < Content-Length: 0
    >     >
    >     >     No "Location" header in the response, compared to what a direct 
request
    >     >     to the backend server sends. I guess this is not the attended 
behaviour.
    >     >
    >     >     >
    >     >     >
    >     >     > Curl output from Apache HTTP:
    >     >     >
    >     >     >> POST /data/request.json?v=1 HTTP/1.1
    >     >     >> Host: <frontend_app>
    >     >     >> User-Agent: curl/7.47.1
    >     >     >> Accept:application/json
    >     >     >> Content-Type:application/json
    >     >     >> Authorization:LivePerson appKey=<key>
    >     >     >> Content-Length: 65
    >     >     >>
    >     >     > * upload completely sent off: 65 out of 65 bytes
    >     >     > < HTTP/1.1 201 Created
    >     >     > < Date: Tue, 14 Feb 2017 19:15:23 GMT
    >     >     > < Server: WS
    >     >     > < Content-Length: 0
    >     >     > < Content-Type: application/json
    >     >     > < Location: https://<fronend_app>/api/<data>/<data>/data/<key>
    >     >     > < P3P: CP="NON BUS INT NAV COM ADM CON CUR IVA IVD OTP PSA 
PSD TEL SAM"
    >     >     > < Connection: close
    >     >     >
    >     >     > Perhaps I need to configure HAProxy differently? I have 
searched the forums and the web, but do not believe I specifically understand 
what is required in order to receive this code from the remote system as I do 
from Apache HTTP.  Is this because HAProxy is configured only to return a 200 
for any successful connection?  Please advise and thank you very much for a 
wonderful product!
    >     >
    >     >     No, haproxy will send the same status code as the backend.
    >     >
    >     >     >
    >     >     > Rob
    >     >     > 970.344.5170
    >     >     >
    >     >
    >     >
    >     >     --
    >     >     Cyril Bonté
    >     >
    >     >
    >
    >
    >     --
    >     Cyril Bonté
    >
    >
    
    
    -- 
    Cyril Bonté
    

Reply via email to