On 26.07.2012 09:44, Stojan Rancic (Iprom) wrote:
On 25.7.2012 11:21, Sander Klein wrote:
We are experiencing the same issue, but it only happens with
Internet
Explorer. So I figured it must be a bug on the internet explorer
side
and not on the HAProxy side since internet explorer doesn't seem to
encode the URL correctly.
I'm afraid I don't have any control over what browsers the users are
using, and I'm sure a fair amount of those are IE . And the fact that
I'm seeing \x escaped characters in both GET and Referrer headers
isn't helping any either.
How do you deal with IE users then ?
This is always a bit problematic.
If the URL is being generated from our software then we fix our
software to create pre-encoded URLs. If it's 3rd party software, we tell
the 3rd party to fix their stuff.
Currently we have one case where the 3rd party doesn't understand the
issue, and then we just tell the users to start using a browser which
does proper encoding.
Because of your question I wiresharked a bit yesterday to make sure I
was giving you the right info. My tests showed that Safari, Firefox and
Chrome do proper encoding of the URL before sending it and Internet
Explorer only encodes some parts of the URL.
I also check RFC3986 and it says in section 2.5 paragraph 6:
---
When a new URI scheme defines a component that represents textual
data consisting of characters from the Universal Character Set [UCS],
the data should first be encoded as octets according to the UTF-8
character encoding [STD63]; then only those octets that do not
correspond to characters in the unreserved set should be percent-
encoded. For example, the character A would be represented as "A",
the character LATIN CAPITAL LETTER A WITH GRAVE would be represented
as "%C3%80", and the character KATAKANA LETTER A would be represented
as "%E3%82%A2".
---
So I definitely think Internet Explorer is doing it wrong. It relies on
the fact that most web servers will encode the URL for them, which most
actually do....
If you really want to accept the 'bad' URLs then you might enable
'option accept-invalid-http-request' but I strongly recommend to not
enable this in a production environment.
Greets,
Sander Klein
