So this confirms what you are saying (see below). Without haproxy in a non-LB environment this works so apparently tomcat on the target openAM server is more lenient. However when I checked the BNF grammar for HTTP headers it doesn't seem to allow /r/r/n. It doesn't explicitely disallow it but the grammar seems clear CRLF is specifically defined as /r/n.
James ----- [13/Sep/2013:10:49:57.723] frontend haproxy (#1): invalid request src 192.168.56.6, session #6, backend haproxy (#1), server <NONE> (#-1) HTTP internal state 26, buffer flags 0x00909002, event #5 request length 455 bytes, error at position 109: 00000 POST /openam/namingservice HTTP/1.0\r\n 00037 User-Agent: OpenAM Web Agent/4.0.0\r\n 00073 Connection: close\r\n 00092 Accept: text/xml\r\r\n 00111 Content-Type: text/xml; charset=UTF-8\r\r\n 00151 Host: openam.gw.com\r\n 00172 *Content-Length: 260\r\n* 00193 \r\n 00195 <?xml version="1.0" encoding="UTF-8" standalone="yes"?>\n 00251 <RequestSet vers="1.0" svcid="com.iplanet.am.naming" reqid="1">\n 00315 <Request><![CDATA[\n 00334 <NamingRequest vers="3.0" reqid="1">\n 00371 <GetNamingProfile>\n 00390 </GetNamingProfile>\n 00410 </NamingRequest>]]>\n 00430 </Request>\n 00441 </RequestSet>\n ----- Original Message ----- From: Lukas Tribus Sent: 09/13/13 03:32 AM To: [email protected] Subject: RE: Receiving 403 errors with no attempt to communicate with the actual server Hi James, please always respond to the mailing list as well. > So the actual sequence when i looked at the binary data is: > > ... > Connection: close/r/n > Accept: text/xml/r/r/n > Content-Type: text/xml; charset=UTF-8/r/rn > Host: openam.gw.com/r/n Did you omit Content-Length or doesn't the request contain it? Please use the "show errors" request on the UNIX stats socket: http://cbonte.github.io/haproxy-dconv/configuration-1.4.html#9.2 Regards, Lukas
