I try to get a php api working, but i monitored requests and php ads a pre- and postfix. no idea why. But its not getting showed in my browser (2c and 0). strange.
here the request:
GET /tasks?dk=123 HTTP/1.1
Host: device.mydomain.eu
Connection: keep-alive
Cache-Control: max-age=0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.114 Safari/537.36
DNT: 1
Accept-Encoding: gzip,deflate,sdch
Accept-Language: de-DE,de;q=0.8,en-US;q=0.6,en;q=0.4
HTTP/1.1 200 OK
Date: Tue, 10 Jun 2014 10:20:20 GMT
Server: Apache/2.2.22
X-Powered-By: PHP/5.4.9
Connection: close
Transfer-Encoding: chunked
Content-Type: application/json
2c
{"tasks":[{"feature":"start","action":"1"}]}
0
any idea?
It's not added by PHP, it is added by Apache. This is due to the chunked transfer. You are receiving one chunk, the first one being 44 characters long (or 2c in hexadecimal notation).
Chunked responses always end with a chunk containing 0 bytes, to indicate the end.
Related
I'm using one of the WooCommerce Appointment plugin and it's causing a 500 internal error.
It seems the Modsecurity intercepts the http access but I don't know what's wrong in the following log.
--a7316b05-A-- [02/Dec/2020:01:37:02 +0800] X8Z-PAqMAA4AAAp171YAAAAE 210.242.3.205 53878 10.140.0.14 443
--a7316b05-B-- GET /wp-admin/admin.php?post_type=wc_appointment&page=appointment_calendar&calendar_month=12&view=month&tab=calendar&filter_appointable_product=&filter_appointable_staff=&calendar_month=11&calendar_year=2020
HTTP/1.1 Host: homie.tw Connection: keep-alive
Upgrade-Insecure-Requests: 1 User-Agent: Mozilla/5.0 (Macintosh; Intel
Mac OS X 10_15_5) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/86.0.4240.198 Safari/537.36 Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.9
Sec-Fetch-Site: same-origin Sec-Fetch-Mode: navigate Sec-Fetch-User:
?1 Sec-Fetch-Dest: document Referer:
https://homie.tw/wp-admin/admin.php?page=appointment_calendar&calendar_year=2020&calendar_month=12&view=month
Accept-Encoding: gzip, deflate, br Accept-Language:
zh-TW,zh;q=0.9,en-US;q=0.8,en;q=0.7,ja;q=0.6,zh-CN;q=0.5 Cookie:
wordpress_sec_39c5768458d20eee442b5f013f95c6e4=chihao.weng%40gmail.com%7C1606879569%7CIYBGng45F7DiEjkIlD5y2rCpJPu7QdupcJsax3TNQmT%7C99241b7eeb1b6d93b810479b22b84ecc4ff13e5394d5798b59840f4f759f649d;
mp_a36067b00a263cce0299cfd960e26ecf_mixpanel=%7B%22distinct_id%22%3A%20%221736f1935d51cd-0a84c5198fb224-31617402-fa000-1736f1935d6df1%22%2C%22%24device_id%22%3A%20%221736f1935d51cd-0a84c5198fb224-31617402-fa000-1736f1935d6df1%22%2C%22%24initial_referrer%22%3A%20%22https%3A%2F%2Fhomie.tw%2Fwp-admin%2Fplugins.php%22%2C%22%24initial_referring_domain%22%3A%20%22homie.tw%22%7D;
_ga=GA1.2.332580245.1599972620; energyplus-u=8d66286c0cdf0413991242985d297257;
wordpress_test_cookie=WP%20Cookie%20check;
tk_ai=woo%3ADAEy5asYphPD0Q3i1p5KUhdQ;
woocommerce_recently_viewed=1106%7C1433%7C1104%7C1105%7C1103%7C1101;
wordpress_logged_in_39c5768458d20eee442b5f013f95c6e4=chihao.weng%40gmail.com%7C1606879569%7CIYBGng45F7DiEjkIlD5y2rCpJPu7QdupcJsax3TNQmT%7C0af3928e6a5cc78caf2d4fc871526abac2817b1604d085a887e9f81a7bc76fe2;
wp-settings-1=libraryContent%3Dbrowse%26editor%3Dtinymce%26hidetb%3D1;
wp-settings-time-1=1606706772; woocommerce_items_in_cart=1;
woocommerce_cart_hash=0737a3efd621083e63e459451c8eb2b8;
wp_woocommerce_session_39c5768458d20eee442b5f013f95c6e4=1%7C%7C1606879577%7C%7C1606875977%7C%7Cf29b691703754018bf8562fa8f40249c
--a7316b05-F-- HTTP/1.1 500 Internal Server Error Expires: Wed, 11 Jan 1984 05:00:00 GMT Cache-Control: no-cache, must-revalidate, max-age=0
X-Frame-Options: SAMEORIGIN Referrer-Policy:
strict-origin-when-cross-origin Content-Length: 2789 Connection: close
Content-Type: text/html; charset=UTF-8
--a7316b05-H-- Apache-Handler: application/x-httpd-php Stopwatch: 1606844220929440 1447814 (- - -) Stopwatch2: 1606844220929440 1447814;
combined=9964, p1=429, p2=8091, p3=65, p4=1265, p5=113, sr=13, sw=1,
l=0, gc=0 Response-Body-Transformed: Dechunked Producer: ModSecurity
for Apache/2.9.1 (http://www.modsecurity.org/); OWASP_CRS/3.2.0.
Server: Apache Engine-Mode: "ENABLED"
--a7316b05-Z--
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 want to cache html page in my browser , and i am tying it on localhost , And I am sending the correct header( using the PHP) in response header but still browser is not caching the response, and every time i request same resource, It connect to server and get response from there
At top of my html page I am using
<?php
header("Cache-Control:max-age=36000");
?>
And the Response headers are
HTTP/1.1 200 OK
Date: Tue, 15 Nov 2016 14:45:37 GMT
Server: Apache/2.4.16 (Win32) OpenSSL/1.0.1p PHP/5.6.12
X-Powered-By: PHP/5.6.12
Cache-Control: max-age=36000
Accept-Ranges: none
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 154
Keep-Alive: timeout=3, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=UTF-8
When i saw Cache-Control:max-age=36000 in headers , I was expecting browser will cache this response for 36000 seconds and if i reload page ,I will get the cached response (and different response header) , but i am getting same header after reload ,and getting response straight from server again ,,
after reload request headers are
GET /check.php HTTP/1.1
Host: localhost
Connection: keep-alive
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.71 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding: gzip, deflate, sdch, br
Accept-Language: en-US,en;q=0.8
Should i send any other response header for tell browser to cache the response ?
PHP (of course) adds some magical cache-control headers by itself. It is not possible to simply overwrite those with header(), and you have to use session_cache_limiter() to set different cache control headers, or session_cache_limiter('') to disable those magical headers all together..
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.
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.