I have many redirections within a VM webserver, which work when browsing the server with the embedded navigator (iceweasel). But that does not work when accessing the server from the hosting machine's browsers (tested with FF4/IE8/Chrome/Opera11).
All experienced redirecting methods are driving to a "server not available or overloaded" in the hosting machine browsers.
If you could have a look to the headers from the apache logs and give some hints about the differences (main one looks to be the GET url, provided that the same code is operating):
Working request leads to this log :
cat /var/log/apache2/access.log | grep 127 | grep random | tail -n1
127.0.0.1 - authuserid [26/Jun/2011:11:11:52 +0200]
"GET /index.php?page=100 HTTP/1.1" 200 49151
"https://www.mydomain.foo/index.php?page=100&new_session=a4da9106dba2ffd40345a5eb624d7788&random=c0117685e7e65a307989c219efc587b4&sid=n7en2it41h2gumrcq3kmmil3c0&sidf=.ps_AWDkIY"
"Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.19) Gecko/2011050718 Iceweasel/3.0.6 (Debian-3.0.6-3)"
Non working request leads to this log :
cat /var/log/apache2/access.log | grep 192 | grep random | tail -n1
www.mydomain.org:80 192.168.X.Y - authuserid [26/Jun/2011:11:08:07 +0200]
"GET /index.php?page=100&new_session=a4da9106dba2ffd40345a5eb624d7788&random=685de8bcd4d198d6ad7f3cf4b23de5b7 HTTP/1.1" 302 -
"http://www.mydomain.foo/index.php?page=xyz"
"Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1"
I can't show the header response as I don't get a response and no error reported by apache (loglevel=error).
Thx
Controls done :
I have increased the browsers timeout (FF: network.http.keep-alive.timeout to 3600s : no change.
I checked that no headers were sent previously to the redirection : ok (a dump of headers_sent() shows no headers sent nor blank line or space in the includes, )
I have increased the Apache server timeout just in case: no change
I made sure of using an absolute url as of HTTP/1.1.
I tried php, html meta and js redirect: no change
EDIT 1:
Here are the headers as seen by LiveHTTPHeaders in the "non working" case :
http://www.mydomain.org/menus/noeud4.php
POST /menus/noeud4.php HTTP/1.1
Host: www.mydomain.org
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-15,utf-8;q=0.7,*;q=0.7
Keep-Alive: 3600
DNT: 1
Connection: keep-alive
Referer: http://www.mydomain.org/index.php?page=890
Cookie: PHPSESSID=4bge5gg1rgkit78k3seqlfcbq2
Authorization: Basic aW52aXRlZEBjYW1hY2FzYTp5b3VybXlndWVzdEB0b2RheQ==
Content-Type: application/x-www-form-urlencoded
Content-Length: 98
login=my_superlogin1&pwd1=vbigpass3xqz%40A2L&captcha=91690& source=noeud4.php&>formulaire_valide=SOUMETTRE
HTTP/1.1 302 Found
Date: Sun, 26 Jun 2011 14:17:27 GMT
Server: Apache/2.2.9 (Debian) DAV/2 SVN/1.5.1 mod_fastcgi/2.4.6 mod_python/3.3.1 Python/2.5.2 >mod_ssl/2.2.9 OpenSSL/0.9.8g PHP/5.3.3
X-Powered-By: PHP/5.3.3
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
Location: http://www.mydomain.org/index.php?page=100&new_session=a4da9106dba2ffd40345a5eb624d7788
Content-Length: 0
Keep-Alive: timeout=60
Connection: Keep-Alive
Content-Type: text/html
http://www.mydomain.org/index.php?page=100&new_session=a4da9106dba2ffd40345a5eb624d7788
GET /index.php?page=100&new_session=a4da9106dba2ffd40345a5eb624d7788 HTTP/1.1
Host: www.mydomain.org
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-15,utf-8;q=0.7,*;q=0.7
Keep-Alive: 3600
DNT: 1
Connection: keep-alive
Referer: http://www.mydomain.org/index.php?page=890
Cookie: PHPSESSID=4bge5gg1rgkit78k3seqlfcbq2
Authorization: Basic aW52aXRlZEBjYW1hY2FzYTp5b3VybXlndWVzdEB0b2RheQ==
HTTP/1.1 302 Found
Date: Sun, 26 Jun 2011 14:19:59 GMT
Server: Apache/2.2.9 (Debian) DAV/2 SVN/1.5.1 mod_fastcgi/2.4.6 mod_python/3.3.1 Python/2.5.2 >mod_ssl/2.2.9 OpenSSL/0.9.8g PHP/5.3.3 X-Powered-By: PHP/5.3.3
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
Location: https://www.mydomain.org/index.php?page=100&new_session=a4da9106dba2ffd40345a5eb624d7788&sid=4bge5gg1rgkit78k3seqlfcbq2&sidf=.ps_Z5wRio
Content-Length: 0
Keep-Alive: timeout=60
Connection: Keep-Alive
Content-Type: text/html
EDIT2:
Comparing both cases of request/responses (working/not working), I isolated the following 2 main differences among others :
On the "working" responses :
Status : 200
which I don't have on the "non working" reponse, but I do not understand why.
on the "NON Working" response :
DNT:1
which stands for the option Do Not Track (me) from FF4.
So I tried to deactivate this option, but same result.
I may miss sthg for sure. All looks as if the server was down. Maybe the session cookie (76 kb) is too big. I also tried downgrading firefox 4 to 3.6 as this another changed parameter, but I still get the same response with FF3.6 as FF4.
As you can see in the requests you posted you try to hit:
http://www.mydomain.org/menus/noeud4.php
but you get redirected to http://www.mydomain.org/index.php?page=100&new_session=a4da9106dba2ffd40345a5eb624d7788 and then again to https://www.mydomain.org/index.php?page=100&new_session=a4da9106dba2ffd40345a5eb624d7788&sid=4bge5gg1rgkit78k3seqlfcbq2&sidf=.ps_Z5wRio
Does it keep sending out 302 headers?
I'm guessing the noeud4.php script is some login script that will likely create a session and probably set some cookies. My guess would be to check if that is being done correctly - and figure out why it's throwing the 302.
Related
While testing the webapp I am working on, I have noticed that firefox seems to be ignoring the cache header for user images.
All such images are loaded through a PHP script, here is a sample response:
Cache-Control: private, max-age=0
Connection: Keep-Alive
Content-Disposition: inline; filename="Immagine.jpg"
Content-Encoding: gzip
Content-Length: 33103
Content-Type: image/jpeg
Date: Thu, 16 Mar 2017 15:24:39 GMT
Etag: allegato-4f04349dba5b5f636a439af71ed75109b701a01d6ac5dfc287dee9729ce4e2098b02e39a2d673789213f5fdf20ceb21a0fc26f17e93e602e38238c3681b9bd00
Expires: Fri, 16 Jun 2017 16:24:40 +0200
Keep-Alive: timeout=5, max=100
Last-Modified: Tue, 16 Jul 2013 10:18:04 +0200
Server: Apache
Vary: Accept-Encoding
and here are the relevant parts of the request sent by firefox:
Host: mywebapp.local
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0
Accept: */*
Accept-Language: it-IT,it;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
I think the issue might be due to FF sending those Pragma and Cache-Control headers, however I checked multiple times and I have caching enabled.
The "same" request on Chrome, which caches correctly, looks like this:
Accept:image/webp,image/*,*/*;q=0.8
Accept-Encoding:gzip, deflate, sdch
Accept-Language:it-IT,it;q=0.8,en-US;q=0.6,en;q=0.4
Connection:keep-alive
DNT:1
Host:mywebapp.local
If-Modified-Since:Tue, 16 Jul 2013 10:18:10 +0200
If-None-Match:allegato-4f04349dba5b5f636a439af71ed75109b701a01d6ac5dfc287dee9729ce4e2098b02e39a2d673789213f5fdf20ceb21a0fc26f17e93e602e38238c3681b9bd00
User-Agent:Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36
How can I determine if this issue is related to my own browser, or rather to the webapp itself?
On Firefox there is one more switch that you have to uncheck in order to disable Cache when the Toolbox is open. You open the Toolbox (Ctrl+Shift+i), navigate to Toobox Options, and uncheck the Disable HTTP Cache when toolbox is open which by default is checked
I use redirects for all of my outbound links, which work fine with the exception of Amazon.
BUT, if I have the actual Amazon link in the HREF it works fine.
Here is an example:
When I redirect the link in the HREF looks something like this:
http://domain.com/buy-web/1425
which goes via an internal PHP script that gets the actual Amazon link, which looks like:
http://www.amazon.com/gp/search?ie=UTF8&tag=AFF_ID&index=aps&linkCode=ur2&camp=CAMP&creative=CREATIVE&keywords=tory-burch-amanda-crossbody-bag
and does:
header('Location: ' . $outURL);
when I redirect I am sent to this page on Amazon instead of the right one:
http://www.amazon.com/ref=nb_sb_noss_null
I have double checked that $outURL has the right link in it.
Anybody got any ideas why?
Thanks everyone.
PS: Here are the raw headers:
http://andynew/buy-web/1026
GET /buy-web/1026 HTTP/1.1
Host: andynew
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:30.0) Gecko/20100101 Firefox/30.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
DNT: 1
Cookie: __atuvc=1%7C28; andynew=a%3A10%3A%7Bs%3A10%3A%22session_id%22%3Bs%3A32%3A%227cb2ce95595fdf811ba5e2163b5f1d24%22%3Bs%3A10%3A%22ip_address%22%3Bs%3A9%3A%22127.0.0.1%22%3Bs%3A10%3A%22user_agent%22%3Bs%3A81%3A%22Mozilla%2F5.0+%28Macintosh%3B+Intel+Mac+OS+X+10.8%3B+rv%3A30.0%29+Gecko%2F20100101+Firefox%2F30.0%22%3Bs%3A13%3A%22last_activity%22%3Bi%3A1406480767%3Bs%3A9%3A%22user_data%22%3Bs%3A0%3A%22%22%3Bs%3A8%3A%22discount%22%3Bs%3A1%3A%220%22%3Bs%3A10%3A%22gridOrList%22%3Bs%3A4%3A%22grid%22%3Bs%3A11%3A%22displayData%22%3Bs%3A3%3A%22rel%22%3Bs%3A8%3A%22currency%22%3Bs%3A1%3A%22%24%22%3Bs%3A9%3A%22productId%22%3Bs%3A0%3A%22%22%3B%7D81d96834d2c29c51fc5169a3b4a3b489
Connection: keep-alive
HTTP/1.1 302 Found
Date: Sun, 27 Jul 2014 18:00:10 GMT
Server: Apache/2.2.25 (Unix) mod_ssl/2.2.25 OpenSSL/0.9.8y DAV/2 PHP/5.4.4
X-Powered-By: PHP/5.4.4
Set-Cookie: andynew=a%3A10%3A%7Bs%3A10%3A%22session_id%22%3Bs%3A32%3A%227de1b339301f44415c2d6e9b6bb4123a%22%3Bs%3A10%3A%22ip_address%22%3Bs%3A9%3A%22127.0.0.1%22%3Bs%3A10%3A%22user_agent%22%3Bs%3A81%3A%22Mozilla%2F5.0+%28Macintosh%3B+Intel+Mac+OS+X+10.8%3B+rv%3A30.0%29+Gecko%2F20100101+Firefox%2F30.0%22%3Bs%3A13%3A%22last_activity%22%3Bi%3A1406484010%3Bs%3A9%3A%22user_data%22%3Bs%3A0%3A%22%22%3Bs%3A8%3A%22discount%22%3Bs%3A1%3A%220%22%3Bs%3A10%3A%22gridOrList%22%3Bs%3A4%3A%22grid%22%3Bs%3A11%3A%22displayData%22%3Bs%3A3%3A%22rel%22%3Bs%3A8%3A%22currency%22%3Bs%3A1%3A%22%24%22%3Bs%3A9%3A%22productId%22%3Bs%3A0%3A%22%22%3B%7D576acce0b2310f850aea22ec8c28ae79; expires=Sun, 27-Jul-2014 20:00:10 GMT; path=/
Location: http://www.amazon.com/gp/search?ie=UTF8&tag=AFF-ID&index=aps&linkCode=ur2&camp=CAMP&creative=CREATIVE&keywords=ugg-classic-bow-shorty-womens-sized-accessory-grey
Content-Length: 0
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html
----------------------------------------------------------
http://www.amazon.com/gp/search?ie=UTF8&tag=AFF-ID&index=aps&linkCode=ur2&camp=CAMP&creative=CREATIVE&keywords=ugg-classic-bow-shorty-womens-sized-accessory-grey
GET /gp/search?ie=UTF8&tag=AFF-ID&index=aps&linkCode=ur2&camp=CAMP&creative=CREATIVE&keywords=ugg-classic-bow-shorty-womens-sized-accessory-grey HTTP/1.1
Host: www.amazon.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:30.0) Gecko/20100101 Firefox/30.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
DNT: 1
Cookie: session-id-time=2082787201l; session-id=185-3040520-0718910; ubid-main=184-2208389-3838529; session-token="Q34hrPBvyfBn/m8gsaJOC185MUqzRj+6pViKhkOotL7DNO+KI3+yGaNFG65xvuN79/agGpPsGKWGN5fDBbt+KAnyq++5PFQSpAkNQnMAsJwMqR+hNzNXYZYr/pwBLe5RbsEF3mjVsACMNNMuzeVKw1OXUhkSO4XNxp+Z6LtlmyWy62KX0x5Qnz2AWy+pgKVFjLfDmHQAe1RMt82gDA0hMbgBZB3dHrko1dKm9o8BZ6I="; x-main="4g66HOBViU1sjppUYDkyRt5qEx7xXo?2"; __utma=125759317.321611390.1405706148.1406480645.1406480704.15; __utmz=125759317.1406478568.13.11.utmccn=(referral)|utmcsr=amazon.com|utmcct=/ap/signin|utmcmd=referral; __utmv=125759317.AFF-ID; x-wl-uid=1eBl7bcTv1V/h74WHTIZP+Hvnsr/oVfw2gl4r2f4jsJRBO2JdOf8BaddaGBLw/itrjEKvX1dbb0YAZxGDfP8eBA==; s_pers=%20s_vnum%3D1408288972388%2526vn%253D1%7C1408288972388%3B%20s_invisit%3Dtrue%7C1405698772388%3B%20s_nr%3D1405696972390-Repeat%7C1413472972390%3B; s_fid=12639358825850B3-1B157A0114E15FF1; s_dslv=1396942038784; s_vn=1418980489687%26vn%3D4; aws-ubid-main=182-0303093-2027858; aws-x-main="?6#eyI2zA2v9U3hUThKr9ptYKZDEnL1u"; regStatus=registered; csm-hit=s-10PZ2HKQV6RQT3SNRG82|1406478566454; __utmc=125759317
Connection: keep-alive
HTTP/1.1 302 Found
Date: Sun, 27 Jul 2014 18:00:10 GMT
Server: Server
x-amz-id-1: 1ENW70JDY98QP5G7R23W
x-amz-id-2: Cgjt+l8Pxxwl5A0t0tAla6b7y5Yobfh45Yq+kRDS4BPgrqyzZMzUmI5YVe3zF4lQej9X7ieHSTw=
X-Frame-Options: SAMEORIGIN
Location: /ref=nb_sb_noss_null
Content-Type: text/html;charset=UTF-8
Content-Length: 0
Set-Cookie: ubid-main=184-2208389-3838529; Domain=.amazon.com; Expires=Sat, 22-Jul-2034 18:00:11 GMT; Path=/
Vary: User-Agent
You aren't sending the URL you claim to be sending. All of your ampersands are being encoded as &, as if this were HTML. Stop doing that, and your problem will go away.
We couldn't tell you what part of your code is doing this unnecessary encoding, since the code you show in your question will not have this problem.
This question already has answers here:
What requests do browsers' "F5" and "Ctrl + F5" refreshes generate?
(6 answers)
Closed 8 years ago.
Here are the request headers:
GET /url/ HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Firefox/24.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
DNT: 1
Cookie: data=ABC;
Connection: keep-alive
Cache-Control: max-age=0
And here is response from the server:
HTTP/1.1 200 OK
Date: Fri, 11 Oct 2013 23:28:32 GMT
Server: Apache/2.2.14 (Ubuntu)
X-Powered-By: PHP/5.3.2-1ubuntu4.18
Expires: Wed, 16 Oct 2013 03:28:32 GMT
Cache-Control: max-age=360000
Pragma: cache
Content-Language: en
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 844
Keep-Alive: timeout=15, max=92
Connection: Keep-Alive
No matter how many times I refresh the page and no matter how, it always makes a request (which takes 200ms+ since it's over HTTPS). Am I overseeing something? Should the response headers contain more parameters in order to prevent Firefox from making a server request?
I normally do something like add example.com/url/?nocache=<?php echo rand(); ?> which will add a random number to the url, making it a different url each time to prevent caching.
The problem sounds like this:
The log-in using sessions works perfect on my localhost, but when the EXACTLY same files are uploaded to my host (hostgator), the sessions don't or, or they get messed up. Also the log-out feature doesn't work on the host.
I've checked and every page has the session_start(); inside it.
The session is not destroyed, even if my logout.php looks like this:
<?php
session_start();
$_SESSION = array();
session_unset();
session_destroy();
header("location:index.php");
exit();
?>
Any suggestions?
I noticed on Firefox with Firebug that your pages are all cached . Your session is working fine, but your page are cached, making login and logout quite (messed up).
Disable HTTP caching for your dynamic pages.
See Firebug output:
Response Headers
HTTP/1.1 304 Not Modified
Date: Thu, 14 Oct 2010 13:16:50 GMT
Server: Apache mod_fcgid/2.3.5 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635
Connection: Keep-Alive
Keep-Alive: timeout=5, max=100
Expires: Thu, 14 Oct 2010 16:16:50 GMT
Cache-Control: public, max-age=10800
Request Headers
GET / HTTP/1.1
Host: www.piataterenuri.info
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10
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
Cookie: PHPSESSID=55aea3f792334052dc673f85feb0b54a
If-Modified-Since: Wed, 13 Oct 2010 13:47:53 GMT
Cache-Control: max-age=0
PHP manual has already an example on how to disable caching:
http://php.net/manual/en/function.header.php
<?php
header("Cache-Control: no-cache, must-revalidate");
header("Expires: Sat, 26 Jul 1997 05:00:00 GMT"); // Date in the past
?>
Firebug shows a request which causes a huge delay to
http://reboltutorial.com/wp-content/themes/minaflow/none
Details below but I don't understand why it says it comes from xmlrpc and the stylesheet:
Date Sun, 04 Apr 2010 16:10:02 GMT
Server Apache
X-Powered-By PHP/5.2.13
X-Pingback http://reboltutorial.com/xmlrpc.php
Expires Wed, 11 Jan 1984 05:00:00 GMT
Cache-Control no-cache, must-revalidate, max-age=0
Pragma no-cache
Set-Cookie wordpress_test_cookie=WP+Cookie+check; path=/; domain=.reboltutorial.com
Last-Modified Sun, 04 Apr 2010 16:10:03 GMT
Vary Accept-Encoding
Content-Encoding gzip
Keep-Alive timeout=2, max=94
Connection Keep-Alive
Transfer-Encoding chunked
Content-Type text/html; charset=UTF-8
RequĂȘtemise en page impression
GET /wp-content/themes/minaflow/none HTTP/1.1
Host: reboltutorial.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; fr; rv:1.9.2) Gecko/20100115 Firefox/3.6
Accept: image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3
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://reboltutorial.com/wp-content/themes/minaflow/style.css
1) Please remove SESSION_ID and all cookies from post (it's quote easy for hacker to access to your site with that)
2) In CSS you have 3 times next code:
background: url(none);
That's why it goes to 404 error!