I have problem using https for the website I'm working on. I'm using spring Security.
Everything work fine in http but when I use https one of my css file is not loaded, and some js file too.
My css file a liked like this
<link type="text/css" rel="stylesheet" href="common/css/gestion_donnees_ref.css>
so this is my request
GET /triWebapp/common/css/donnees_ref.css HTTP/1.1
Host: 10.24.192.169:444
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0
Accept: text/css,*/*;q=0.1
Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Referer: https://10.24.192.169:444/triWebapp/gestionDonneesReference
Cookie: JSESSIONID=eYvbCpcb2NNY4zvWtah3Rfhp
Connection: keep-alive
and the response
HTTP/1.1 302 Found
Date: Mon, 24 Nov 2014 15:43:08 GMT
Server: Apache
Location: http://tipi.hd.prod.me.edf.fr/triWebapp/common/css/donnees_ref.css
Content-Length: 250
Connection: close
Content-Type: text/html; charset=iso-8859-1
it seems that the conent type is wrong here but I don't know why.
Related
I am working on a web file share service, the service can decompress the .gz file content before transferring to client if user asks for it: Windows has not gzip build-in.
Following is an example: un-gzip and download long.txt.gz.
Capture from Fiddler
Request
GET https://szdc-data-explorer-test.spiral.exchange/v1/fs/file/tmp/long.txt.gz?pipelines=ungzip&file_name=long.txt&otk=da39a3ee5e6b4b0d3255bfef95601890afd80709 HTTP/1.1
Host: szdc-data-explorer-test.spiral.exchange
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:96.0) Gecko/20100101 Firefox/96.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
DNT: 1
Connection: keep-alive
Referer: https://next-test.spiral.exchange/
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-site
Response
HTTP/1.1 200 OK
Cache-Control: no-store
Content-Disposition: attachment; filename="long.txt"
Content-Type: text/plain; charset=UTF-8
Date: Thu, 13 Jan 2022 00:44:14 GMT
Vary: Accept-Encoding
Vary: Origin
Content-Length: 293216
Firefox save the file with name long.txt as specified in Content-Disposition header, but the content is gzip-ed. It sounds like Firefox auto gzip due to request path ends with .gz: /v1/fs/file/tmp/long.txt.gz
Well, it is a known behavior of firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=610679
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
I have a Java program which forwards the HTTP request from clients to INTERNET and write back the response to client. But when clients trying Google.com from their browser i am getting 302 found Response from Internet.
Here is the Request from client :
GET http://google.com/ HTTP/1.1
Host: google.com
Proxy-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 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.118 Safari/537.36 OPR/28.0.1750.51
DNT: 1
Accept-Encoding: gzip, deflate, lzma, sdch
Accept-Language: en-US,en;q=0.8
Cookie: PREF=ID=0168c274e46046ff:FF=0:LD=en:TM=1427909641:LM=1428321915:GM=1:S=HGTpo1ahuPUd4Nu2; SID=DQAAAPgAAACOH1NUVCRnVJfjL-W4MtbTmqx9yY1Wbra4LM7D8_uslXU_43zD4QrZl4eHqBuukNoKFw0gD68Vt7DltSgBrOoVRufDgeLImP8321g2-IxjmtqwjJoI9sSM3YEwC5ZvnTNyrwuHhBp-zZqImsaHshVmvt8GEV1WDFHs4OZ74g219CeKYztHKjsQLDS_yZ725qsIKWjvbb_NlnO5IqktZ0Q6JXIMRPzshZQvoq7ZiwH9RfiIASpHIiFC1XDwrMZDcbONpKCke2QxZtmxSPfUHXuBx53bJOZFHUrcAJAvihBAXoFwZHUr2beVtRuLe1w8blbt6AGTy9dT9gZ9nVjeSHzK; HSID=Aso16-EnwP4siCr5Q; APISID=DIHL_mSdprkZSELD/AjGWXXsjCWUT9FEuy; NID=67=DGyWJrkoHYqgDmpEMmQVlnzZQLlwGNTxbAZ8--PQeTPlZ4SbL3AbFNP40h0NOI3ztb_6SkDTHwGJonmESsToDR6Vkmur0VST-6k34xVvQM9FQH_PaoMrK8O6kT0Avd8FIITl7G7ERJbvbwWIsCuhIwZOR2cj2r6aCmnM27A
This is the Response i got :
HTTP/1.1 302 Found
Cache-Control: private
Content-Type: text/html; charset=UTF-8
Location: http://www.google.co.in/?gfe_rd=cr&ei=Uhw7Vbe6H_PI8Ae_qICIBA
Content-Length: 261
Date: Sat, 25 Apr 2015 04:47:14 GMT
Server: GFE/2.0
Alternate-Protocol: 80:quic,p=1
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>302 Moved</TITLE></HEAD><BODY>
<H1>302 Moved</H1>
The document has moved
here.
</BODY></HTML>
Is this because Google using HTTPS instead of HTTP. and it is trying to redirect the request...?
But how i should process this reply?
I send the same response to client. But no redirection is happening,
What should i do?
From the Location header in the Http Response, seems that Google detected that the call came from India and it's redirecting the call to Google India i.e. http://www.google.co.in/?gfe_rd=cr&ei=Uhw7Vbe6H_PI8Ae_qICIBA.
When you get a 302 response your client should react properly and follow the call to the Location header.
Sometimes it is an issue about ipv6 transaction against ipv4.
Try disable ipv6 in your server and reboot with:
echo net.ipv6.conf.all.disable_ipv6=1 > /etc/sysctl.d/disableipv6.conf
I've implemented a web application that takes advantage of CORS to gather JSON data from another server. The servers run on different subdomains. Everything seems implemented correctly, and it works fine with Chromium. Below is a copy of my requests, from Chromium.
My problem is that in Firefox (tested with 13.0.1), no request is ever made for my AJAX resource. No preflight request is ever sent, and no actual request is made. Instead, I get this error, from the XMLHttpRequest.send() function:
[21:40:27.546] uncaught exception: [Exception... "Access to restricted URI denied" code: "1012" nsresult: "0x805303f4 (NS_ERROR_DOM_BAD_URI)" location: "http://192.168.1.99:2502/static/mootools-core-1.4.5.js Line: 5398"]
I am using Mootools' Request.JSON object, which sets various extra headers, meaning that a preflight would indeed be required. However, it is never sent.
Unfortunately, JSONP is not an option, as the data is sensitive.
Does anyone have insight into what the problem could be?
Thanks very much.
Working example, from Chromium:
Preflight request:
OPTIONS /api/resource HTTP/1.1
Host: dev0.mydomain.com
Connection: keep-alive
Access-Control-Request-Method: GET
Origin: http://192.168.1.99:2502
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.19 (KHTML, like Gecko) Ubuntu/12.04 Chromium/18.0.1025.151 Chrome/18.0.1025.151 Safari/535.19
Access-Control-Request-Headers: origin, x-request, x-requested-with, accept
Accept: */*
Referer: http://192.168.1.99:2502/
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Cookie: [redacted]
Preflight response:
HTTP/1.0 200 OK
Server: PasteWSGIServer/0.5 Python/2.7.3
Date: Fri, 29 Jun 2012 01:43:37 GMT
Content-Length: 0
Access-Control-Allow-Headers: Cookie, Origin, X-Request, X-Requested-With, Accept
Access-Control-Max-Age: 1
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: http://192.168.1.99:2502
Access-Control-Allow-Methods: GET
Content-Type: text/html; charset=UTF-8
"Real" request:
GET /api/resource HTTP/1.1
Host: dev0.mydomain.com
Connection: keep-alive
Origin: http://192.168.1.99:2502
X-Request: JSON
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.19 (KHTML, like Gecko) Ubuntu/12.04 Chromium/18.0.1025.151 Chrome/18.0.1025.151 Safari/535.19
Accept: application/json
Referer: http://192.168.1.99:2502/
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Cookie: [redacted]
"Real" response:
HTTP/1.0 200 OK
Server: PasteWSGIServer/0.5 Python/2.7.3
Date: Fri, 29 Jun 2012 01:43:37 GMT
Access-Control-Allow-Origin: http://192.168.1.99:2502
Content-Type: text/html; charset=UTF-8
Content-Length: 22
Access-Control-Allow-Credentials: true
The answer is given in the comments to the question. Firefox was not sending the request due to the HTTP authentication username I had provided.
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?