Hi, no unfortunately, it is the OpenAM sample apache policy agent. None of it is my code but if I have time I'll see if I can track it down and submit a bug report to them.
In the mean time, I found that their sample Tomcat policy agent doesn't exhibit the same problem so I'll use that in my evaluation. Incidentally, I did try using the TCP mode of haproxy and that seems to work ok with the broken Apache 2.2 agent. James p.s. thanks for all who helped on this. ----- Original Message ----- From: Willy Tarreau Sent: 09/15/13 02:44 AM To: Lukas Tribus Subject: Re: Receiving 403 errors with no attempt to communicate with the actual server Hi Lukas, On Fri, Sep 13, 2013 at 07:41:13PM +0200, Lukas Tribus wrote: > Hi! > > > > Wouldn't the extra '\r' be swallowed as part of the 'text/xml' value of > > the Accept: header? > > Yes, but \r is not allowed as character in header values either. > > > The question was rather, can we make haproxy ignore this with > option accept-invalid-http-request > > Looks like we cannot. Indeed it will not accept it. This option mostly unlocks the syntax filtering on places where it is not critical (eg: forbidden characters in header names, such as '/'). But characters which break the framing are not unlockable. The only character allowed after a CR is LF, this is a two-character sequence for an end of line, we must absolutely not allow half an end of line to pass through because random behaviours will happen. > > Whatever the way your turning this, the server doesn't respect rfc, > > that's all. > > Fix the broken server > > Fix the application, as simple as that, yes. I even doubt i t's the application, I suspect some crap was inserted between the client and the server to insert the two lines before an end of line to force these headers, but doing it before the LF fails for the reason we're seeing (or that hack should be modified for not inserting the CR anymore). Willy
