Firefox sending two get request for a website - firefox

Clicking a link results in two calls for the page to the server. I install livehttp and inspected the header but can't figure out why it's sending the second request.
http://example.com/schedule?delete=290376
GET /schedule?delete=290376 HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20110207 Firefox/3.6.13
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://example.com/schedule
Cookie: Code=XXX; CodeHash=XXXXX
HTTP/1.1 200 OK
Date: Tue, 01 Mar 2011 22:09:51 GMT
Server: Apache
X-Powered-By: PHP/5.2.17
Set-Cookie: Code=XXXX; expires=Wed, 02-Mar-2011 00:09:52 GMT; path=/
Set-Cookie: CodeHash=XXXX; expires=Wed, 02-Mar-2011 00:09:52 GMT; path=/
Keep-Alive: timeout=2, max=200
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html
----------------------------------------------------------
http://example.com/schedule?delete=290376
GET /schedule?delete=290376 HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20110207 Firefox/3.6.13
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://example.com/schedule
Cookie: Code=XXXX; CodeHash=XXXXX
HTTP/1.1 302 Moved Temporarily
Date: Tue, 01 Mar 2011 22:09:55 GMT
Server: Apache
X-Powered-By: PHP/5.2.17
Set-Cookie: Code=XXX; expires=Wed, 02-Mar-2011 00:09:55 GMT; path=/
Set-Cookie: CodeHash=XXX; expires=Wed, 02-Mar-2011 00:09:55 GMT; path=/
Location: http://example.org/schedule?errors=5
Keep-Alive: timeout=2, max=200
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html
----------------------------------------------------------

In case you didn't find your solution:
I have stumbled on that same issue, and it seems to be related to the page encoding. If FireFox downloads a page containing invalid characters (for example, utf-8 chars inside a page for which the Content-type header is something else), then it will download the page a second time and parse it in the encoding it has tried to guess from the invalid chars it detected in the first page.
So make sure your page either returns the correct Content-type header, or contains a meta http-equiv header with the correct encoding.

You don't happen to be using firefox, have the web developer toolbar and also have the display page validation on do you?
I am guessing in the dark here as to your enviro but my team and I have been able to demonstrate that having that tool bar installed in firefox and having page validation set to display actually duplicates the POSTs and GETs as it sends that same page data to the validation service.

Related

JSF ajax requests causing a page refresh on specific browser

I have a web application developed with Java 7, PrimeFaces 5 (JSF), Tomcat 7. Some time ago a user reported a defect from production environment where everything he clicked caused the page to be refreshed. I couldn't reproduce it then I forgot about it... but right now I just reproduced the issue, for the first time, running the application in my local machine. Any button I click, that triggers an ajax request, will be followed by a page refresh. I tried to restart tomcat and to clear Chrome's cache with CMD+SHIFT+R but I still can reproduce the issue.
I can reproduce on Google Chrome, but not on Firefox and Safari. I opened the network tab from Developer Tools from both Firefox and Chrome to compare the requests... but I still can't understand... does anybody have any idea what may be happening?
I will provide below the network activities for the following close event:
<p:panel id="myPanel" widgetVar="myPanelVar" closable="true">
<p:ajax event="close" listener="#{myBean.changeSomeVariables}" />
<h:outputText value="Example panel"/>
<a onclick="PF('myPanelVar').close();"><span class="ui-icon ui-icon-closethick"></span></a>
</p:panel>
Network activity from Firefox (working fine):
Request URL:http://localhost:8080/myMainPage;jsessionid=3BF25F4A5CF149326D3561C0F2002FB9
Request Method:POST
Status Code:200 OK
Remote Address:[::1]:8080
REQUEST HEADERS:
Host: localhost:8080
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:48.0) Gecko/20100101 Firefox/48.0
Accept: application/xml, text/xml, */*; q=0.01
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Faces-Request: partial/ajax
X-Requested-With: XMLHttpRequest
Referer: http://localhost:8080/myMainPage
Content-Length: 309
Connection: keep-alive
RESPONSE HEADERS:
Cache-Control: no-cache, no-store, must-revalidate, no-cache
Content-Length: 335
Content-Type: text/xml;charset=UTF-8
Date: Sun, 21 Aug 2016 03:02:14 GMT
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Pragma: no-cache
Server: Apache-Coyote/1.1
FORM DATA:
javax.faces.partial.ajax=true&javax.faces.source=myPanel&javax.faces.partial.execute=myPanel&javax.faces.behavior.event=close&javax.faces.partial.event=close&myHeaderForm=myHeaderForm&myHeaderForm%3Aemail=userTest&myHeaderForm%3Apassword=passTest&javax.faces.ViewState=3276447570579140768:319272761245257759
Network activity from Chrome (not working fine, I don't understand where the GET request is coming from):
Request URL:http://localhost:8080/myMainPage
Request Method:POST
Status Code:200 OK
Remote Address:[::1]:8080
REQUEST HEADERS:
POST /myMainPage HTTP/1.1
Host: localhost:8080
Connection: keep-alive
Content-Length: 325
Origin: http://localhost:8080
Faces-Request: partial/ajax
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Accept: application/xml, text/xml, */*; q=0.01
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36
Referer: http://localhost:8080/myMainPage
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.8,pt;q=0.6
Cookie: JSESSIONID=5C1AE4DB6B1B5148BD81FD0E47002EA4
RESPONSE HEADERS:
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Set-Cookie: JSESSIONID=B68E094F6CF3C5AD57D96F0D1823AEBD; Domain=.mySite.com; Path=/; HttpOnly
Cache-Control: no-cache
Content-Type: text/xml;charset=UTF-8
Content-Length: 76
Date: Sun, 21 Aug 2016 03:05:36 GMT
FORM DATA:
javax.faces.partial.ajax=true&javax.faces.source=myPanel&javax.faces.partial.execute=myPanel&javax.faces.behavior.event=close&javax.faces.partial.event=close&myHeaderForm=myHeaderForm&myHeaderForm%3Aemail=userTest&myHeaderForm%3Apassword=passTest&javax.faces.ViewState=8492705007558548241%3A8154221161100277529
__________________________________________________________
Request URL:http://localhost:8080/myMainPage
Request Method:GET
Status Code:200 OK
Remote Address:[::1]:8080
REQUEST HEADERS:
GET /myMainPage HTTP/1.1
Host: localhost:8080
Connection: keep-alive
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Referer: http://localhost:8080/myMainPage
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8,pt;q=0.6
Cookie: JSESSIONID=5C1AE4DB6B1B5148BD81FD0E47002EA4
RESPONSE HEADERS:
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Set-Cookie: JSESSIONID=D352B9B5644288F3095D1A702075AFEB; Domain=.mySite.com; Path=/; HttpOnly
Content-Type: text/html;charset=UTF-8
Transfer-Encoding: chunked
Content-Encoding: gzip
Vary: Accept-Encoding
Date: Sun, 21 Aug 2016 03:05:36 GMT
Thanks

Chrome not setting cookie on AJAX POST

I do an AJAX POST to my webservice, and it sets 2 cookies in the response, but Chrome does not set them. Safari and Firefox do, however.
Here's the request:
POST /api/login HTTP/1.1
Host: 0.0.0.0:8080
Connection: keep-alive
Content-Length: 50
accept: application/json
Origin: http://0.0.0.0:8080
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.80 Safari/537.36
content-type: application/json
Referer: http://0.0.0.0:8080/form
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.8,nl;q=0.6,de;q=0.4,fr;q=0.2,pl;q=0.2
Response:
HTTP/1.1 200 OK
X-Powered-By: Express
Vary: X-HTTP-Method-Override, Accept-Encoding
x-frame-options: sameorigin
set-cookie: keystone.uid=s%3A55efe88923f753865f7a0985%3Ac5aT64aih9lxXi%2BNiSMr1rUJW4kzWyyNUforvUOrckk.JovuV%2FqeoQ32PiuyNPAZ7JcbIxXBcBvj%2FWFp8vf3SQQ; Path=/; HttpOnly
set-cookie: keystone.sid=s%3ADcv5el-TjLRkOSH9vNbvxQoOai-SQj-3.ZTfPFwEZp5mdVHSDZTukO%2FnrDnSpGU3OMW3tQu%2FSz7U; Path=/; HttpOnly
Content-Type: application/json; charset=utf-8
Content-Length: 224
ETag: W/"e0-B6OeRPdDEP0WPVdlZHqarA"
Date: Fri, 06 Nov 2015 14:39:37 GMT
Connection: keep-alive
I'm out of ideas. This doesn't work with a fully qualified domain name on port 80 either.
Found the solution:
You have send the request with credentials (XMLHttpRequest.withCredentials or e.g. credentials: 'include' for whatwg fetch).
Even though this is pointless since you're logging in and don't have any/have invalid cookies, it makes Chrome store the cookies from the returned answer. ¯\_(ツ)_/¯
As pointed out by #Anne, the XMLHTTPRequest specification actually requires user agents to disregard returned cookies unless withCredentials is specified. http://www.w3.org/TR/XMLHttpRequest/#the-withcredentials-attribute

Parse Security: able to see request/response in plain-text via proxy server

I'm attempting to hack the Parse SDK, and it seems that we are able to see requests and responses in plain text via a proxy server between Parse and the app. I assumed the data was encrypted, but a malicious user is able to see our requests and modify them to essentially pull out all of our user information.
Does anyone have any ideas on this?
Here is an example of a custom request and response via Proxy:
POST /1/classes/_User HTTP/1.1
Host: api.parse.com
Content-Type: application/json; charset=utf8
Cookie: _parse_session=---
Accept: */*
Proxy-Connection: keep-alive
X-Parse-Application-Id: ---
X-Parse-Client-Key: ---
X-Parse-Installation-Id: ---
Accept-Encoding: gzip, deflate
X-Parse-OS-Version: 8.2 (12D508)
Accept-Language: en-us
X-Parse-Client-Version: i1.6.5
Content-Length: 51
Connection: keep-alive
X-Parse-App-Build-Version: 11
X-Parse-App-Display-Version: 1.0.0
{"where":{"email":"joe#joe.com"},"_method":"GET"}
HTTP/1.1 200 OK
Access-Control-Allow-Methods: *
Access-Control-Allow-Origin: *
Content-Type: application/json; charset=utf-8
Date: Fri, 10 Apr 2015 01:02:55 GMT
Server: nginx/1.6.0
X-Parse-Platform: G1
X-Runtime: 0.013113
Content-Length: 246
Connection: keep-alive
{"results":[{"company":"","createdAt":"2015-04-10T01:02:35.670Z","discoverable":true,"email":"joe#joe.com","firstName":"Joe","lastName":"Smith","objectId":"yPTx1kyHei","title":"","updatedAt":"2015-04-10T01:02:35.670Z","username":"joe#joe.com"}]}

Firefox/Mozilla personas errors -- URL change?

Has the location for Firefox/Mozilla personas changed? Looking at the error console I see:
GET https://addons.cdn.mozilla.net/en-US/firefox/_files/245568/firefoxtom.jpg [HTTP/1.1 404 Not Found 299ms]
Redownloading the persona gives:
GET https://addons.cdn.mozilla.net/user-media/addons/245568/firefoxtom.jpg [HTTP/1.1 200 OK 756ms]
For all my current personas, I only see the background color, not the image. Has something changed recently? Is there a workaround? FF 31. Thanks!
Hearing nothing, I'll assume it's a web server misconfiguration on Mozilla's part and that no one cares. Just for posterity, here is the request/response that I tried to post in comments above, but that didn't look very good.
https://addons.cdn.mozilla.net/_files/245568/firefoxtom.jpg?1288084876
Request Method: GET
Status Code: HTTP/1.1 301 Moved Permanently
Request Headers 09:25:39.000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:32.0) Gecko/20100101 Firefox/32.0
Host: addons.cdn.mozilla.net
Connection: keep-alive
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Accept: image/png,image/*;q=0.8,*/*;q=0.5
Response Headers Δ305ms
X-Frame-Options: DENY
X-Backend-Server: web7
Vary: Accept-Language, User-Agent, X-Mobile
Strict-Transport-Security: max-age=31536000
Server: nginx
Location: https://addons.cdn.mozilla.net/en-US/firefox/_files/245568/firefoxtom.jpg?1288084876
Date: Sun, 07 Sep 2014 15:25:41 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 0
Cache-Control: max-age=31536000

mod_rewrite condition and rule effects POST vars in a bad way

I have 2 domains mydomain.com and mydomain.org. The site lives at mydomain.org so I want any attempt to mydomain.com to resolve to mydomain.org.
The following mod_rewrite rule that works to a degree.
RewriteEngine on
RewriteCond %{HTTP_HOST} ^mydomain\.com$
RewriteRule ^ http://mydomain.org%{REQUEST_URI} [L,R=301]
After I implemented it and tested it I felt it was doing everything I needed until I submitted a form with method="post".
For some reason, this mod_rewrite trashes my _POST vars
I am working solely from mydomain.org (which is the TLD I want the site to resolve from and where I submitted the form from).
Does anyone know of an adjustment to my condition and rule to not lose the _POST vars?
I identified something interesting. I plugged-in the HTTP Live Headers add-on in Firefox. When I use the mod_rewrite I get an "HTTP/1.1 404 Not Found" and when I turn off mod_rewrite I get a "HTTP/1.1 200 OK". The same page and PHP code behind is used. Again, when I have the mod_rewrite directives turned off, the _POST data comes through. When I turn on the mod_rewrite directives, the _POST data does not come through.
MOD_REWRITE Turned Off:
http://dashausmuseum.org/subscribe.html
POST /subscribe.html HTTP/1.1
Host: dashausmuseum.org
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20100101 Firefox/5.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Referer: http://dashausmuseum.org/subscribe.html
Cookie: __utma=74430599.461726749.1312575846.1312897084.1312899646.5; __utmz=74430599.1312575846.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utma=1.480711209.1312899756.1312979975.1312981669.5; __utmz=1.1312981669.5.5.utmcsr=dashausmuseum.com|utmccn=(referral)|utmcmd=referral|utmcct=/directions.html; __utmb=1.9.10.1312981669; PHPSESSID=7f4a74d7fde56cf901aa85511410b7f6; __utmc=1
Content-Type: application/x-www-form-urlencoded
Content-Length: 60
email=abc&firstName=&lastName=&address=&phone=&submit=Submit
HTTP/1.1 200 OK
Date: Wed, 10 Aug 2011 13:18:31 GMT
Server: Apache/2.2.17 (Unix) mod_ssl/2.2.17 OpenSSL/0.9.8e-fips-rhel5 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635 PHP/5.3.4
X-Powered-By: PHP/5.3.4
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-Length: 5420
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html
MOD_REWRITE Turned On:
http://dashausmuseum.org/subscribe.html
POST /subscribe.html HTTP/1.1
Host: dashausmuseum.org
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20100101 Firefox/5.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Referer: http://dashausmuseum.org/subscribe.html
Cookie: __utma=74430599.461726749.1312575846.1312897084.1312899646.5; __utmz=74430599.1312575846.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utma=1.480711209.1312899756.1312979975.1312981669.5; __utmz=1.1312981669.5.5.utmcsr=dashausmuseum.com|utmccn=(referral)|utmcmd=referral|utmcct=/directions.html; __utmb=1.10.10.1312981669; PHPSESSID=7f4a74d7fde56cf901aa85511410b7f6; __utmc=1
Content-Type: application/x-www-form-urlencoded
Content-Length: 60
email=xyz&firstName=&lastName=&address=&phone=&submit=Submit
HTTP/1.1 404 Not Found
Date: Wed, 10 Aug 2011 13:20:32 GMT
Server: Apache/2.2.17 (Unix) mod_ssl/2.2.17 OpenSSL/0.9.8e-fips-rhel5 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635 PHP/5.3.4
X-Powered-By: PHP/5.3.4
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-Length: 5329
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html
Does anyone see anything in the HTTP Headers that gives a clue as to what is going on?
Something else should be wrong, rewrite rules can't destroy _POST vars.
How are you setting/calling them in your code?
There is some discussion about what should happen to a POST transaction in response to a 301 (or other) redirect. Here is one example where the author suggests it is "messy".
Is it possible your browser is converting the POST to a GET request? Is it also possible the behavior is different in different browsers?

Resources