Ngnx 1.2.3 truncated Facebook code parameter value because of "#"

i use Facebook authentication with my website.

I use Nginx 1.2.3.

Facebook produce URL with the following pattern :

=">https://www.mysite.net/profile.xhtml?state=dfecc191-5eb5-4e08-a514-bc70fdc17611&code=AQBKJ_1VuycE7-DPigKfrAt9BLGQJww-p0RKY_Lta6uDxsaMUgzR98soPiOD6NDZ6kyU-NJUHmpAqEOSCxOKi7UGgh0fJSfC9kyh18FtSbQNJdyNEkkfaNtP9GMC8y25W6fOjyR2fj3OnQQTFDwmm-gckqofvhJsmnPSWgHxaan7uiaz_Wgc5JcdTu2DfzhOjqUQ_QG7X14jWDdq9CUtHuSV#=

As you can see facebook add #_=_ at the end of code parameter value.

Now, if you try to build any kind of URL GET with a # in it, NGINX will stop to parse the request when it encountered #, this for instance.

Gives the following log :

[16/Aug/2012:11:25:33 +0200] "GET /index.html?value1=jo HTTP/1.1" 200 4976 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.79 Safari/537.1"

In my case, Nginx stops to parse the request and remove "#=" from code parameter value !

Any idea ?

Thanks.

PS: this works perfectly well with Apache.

Answers


So the way that server's handle hashes (the #_=_) is that they generally ignore it.

This hash should have no bearing on whether or not the code returned by facebook should work.

What will affect it's success is casing. Make sure you're not calling .ToLower() (or similar) on the request parameters before you try and use the code.

Hope this helps!


I think you are mistaking - no browser (expect IE if you confuse it) will ever send the fragment portion of the URL to the server - that is agains the HTTP specification.

That you say this works with Apache is close to impossible.

Your example is a perfectly valid URL, but the URI part is http://www.mysite.net/index.html?value1=jo since #hn&value2=doe is in fact the fragment part of the URL.


Need Your Help

Why Doesn't preg_match return data? Design Decision?

php preg-match

I was wondering if there was a programmatic reason why php developers chose to not have preg_match return data.