Because this bug could affect a large number of backends
(cgi/fastcgi/proxy), nginx should remove the anchor part of the URL
before passing it on to any other service.
That sounds like something someone should do in a config file , to
match with certain versions of IE
# is invalid... it should be encoded and sent as a %23 -- but i can
see the possibility of breaking more browsers by stripping it, than
by leaving it in and just having a user-defined browser match regex
for ie
Yes, it is invalid, and since it is invalid, the theoretical correct
action should be a 400 Bad Request, but since this is production IE
bug, that would definitely break things. If the # was re-interpreted
as %23, it would cause a 404 error. It's also noteworthy that you get
a 404 if you are requesting a local file with nginx (I assume it looks
for the file "#bar" instead of the index for a request to "/#bar").
The only real solution is to strip off that portion of the URL.
FWIW, Apache2.2 seems to strips off the anchor to handle this case.
That certainly doesn't make me right, nginx isn't apache. (My test was
simply testing a production site I know runs Apache2.2 + Mongrel +
Rails and I didn't get an error.)
You're right, it can be a config file thing - I will add stripping of
anchors regardless of browser (because it should never be sent) - but
unless *everyone* has it in their config file I think it's still a
problem - people will blame nginx when they run across this.
5 messages in ru.sysoev.nginxRe: Re: weird anchor bug
.txt
