js files being requested instead of using cache directly - http

I am using chrome to load a web page twice. On the second load, I still see all the js files being requested with 304 of course returned. I see the css files NOT requested and just load from cache. why is my js not loading from cache?
From chrome, here is the request/response on the second time(and on the third time it is re-requested instead of listenting to cache-control:max-age=3600
Request URL:http://myextremestore.com/public/js/bootstrap/theme.js
Request Method:GET
Status Code:304 Not Modified
Request Headersview source
Accept:*/*
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8,zh-CN;q=0.6,zh;q=0.4
Cache-Control:max-age=0
Connection:keep-alive
Cookie:_ga=GA1.2.1887017343.1389240672; _usrp_dbba204e-e224-4c2e-9715- 645207f1698c_0=eyJMYXN0VmlzaXRUaW1lIjoxMzg5ODEwNzk2LCJTZXNzaW9uTnVtYmVyIjoxNCwiSXNTZXNzaW9uVmlzaXRMb2dnZWQiOmZhbHNlLCJUcmllZFRvSW52aXRlIjp0cnVlLCJTZXNzaW9uUGFnZVZpZXciOjE1LCJUb3RhbFBhZ2VWaWV3Ijo1MywiTG9jYWxRdWFyYW50aW5lIjpudWxsLCJXYXNJbml0QW1pbmF0aW9uIjp0cnVlfQ==; PLAY_SESSION="4c82c3ec3facde8b5cdd167313527d0b9b7b91df-s=500&___AT=df52f59436377f3500fb5700808f35bd5631e539&key=dean%40buffalosw.com"
Host:myextremestore.com
If-Modified-Since:Wed, 08 Jan 2014 18:48:42 GMT
If-None-Match:"1389206922000-1544568346"
Referer:http://myextremestore.com/admin/products
User-Agent:Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36
Here is the response
Response Headersview source
Cache-Control:max-age=3600
ETag:"1389206922000-1544568346"
Server:Play! Framework;master-5afad9b;prod
I am testing this on http://myextremestore.com and for some reason firefox is working just fine and I only see a single request server side when using firefox but chrome keeps asking for the same js files.
IE11 is working just fine as well. This is very weird.
Any ideas appreciated.
thanks,
Dean

oh, so it turns out in chrome hitting enter in the url window results in same behavior as pushing the refresh button!!! In firefox, hitting enter in the url does NOT result in hitting the refresh button.
I do not however know why chrome on refresh is only asking for js files and not asking for css files...that seems weird. Anyways, it works as I expect now.

Related

Microsoft Edge 14 options request response not received?

I'm trying to load a JSON file from my CDN, and all browsers work except MS Edge. When I inspect the network tab of Edge, I see that the OPTIONS requests that preceed the request to the actual JSON file keep their "pending" status, and the response headers as well as the response body stay empty in that panel, as shown in the screenshot below :
When I reload the page, the files that I was trying to fetch show up, before even my page request, and are shown to have taken many seconds to load (here, 3887 seconds) :
My server is definite that a 200 response was sent as a response to the initial OPTIONS request :
method: "OPTIONS"
resource: "/lang/locale-survey-en_US.json?1490092072501"
httpVersion: "HTTP/1.1"
status: 200
responseSize: "175"
userAgent: "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.79 Safari/537.36 Edge/14.14393"
My best guess is that Edge is not able to read the response to the OPTIONS request, but if so why would it send OPTIONS requests in the first place ? As it works in all other browsers, I'm out of ideas about how I can debug this, so if you have suggestions about which logs or what I should check, any help will be greatly appreciated.

Jetty client http error code 412

I am accessing one website (I am hiding origin website name as it is against the policy) using browser and jetty/apache httpclient.
The website works fine with web browser.
Using api I am able to login into website,gets the session cookie JSESSIONID and home page html content. But after that when I submit any form or call the links from html I receive the HTTP error code 412(Pre condition failed).
I understand this error is due problem in client header. I set all the headers from browser(checked using inspect element in chrome browser). Still I have the same error.
I am not able to track down which header is causing the problem.
Here is the Header from browser
Request Headers
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,/;q=0.8
Accept-Encoding:gzip, deflate
Accept-Language:en-GB,en-US;q=0.8,en;q=0.6
Cache-Control:max-age=0
Connection:keep-alive
Content-Length:318
Content-Type:application/x-www-form-urlencoded
Cookie:language=en_IN; __gads=ID=14c64d8f9fd7de54:T=1424658276:S=ALNI_Mba1kvJO4mLo7R-T2jUJE9zCYck5A; SLB_Cookie=ffffffff09461c2d45525d5f4f58455e445a4a422971; JSESSIONID=36m4Oo6dCML_Wvx-Wgmm9rtLh9mbURxnZhWIVwg-zHaNzFQeUt9C!-1989013783; _ga=GA1.3.379900459.1428120216
Host:www.irctc.co.in
Origin:https://www.example.com
Referer:https://www.example.com/context/home
Upgrade-Insecure-Requests:1
User-Agent:Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.157 Safari/537.36
Same header I am setting from jetty client.
Request request = httpClient.newRequest(url);
request.method(HttpMethod.POST);
request.agent(USER_AGENT);
request.accept("text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8");
request.header(HttpHeader.REFERER,"https://www.example.com/context/home");
request.header(HttpHeader.ACCEPT_ENCODING, "gzip, deflate");
request.header(HttpHeader.ACCEPT_LANGUAGE, "en-GB,en-US;q=0.8,en;q=0.6");
request.header(HttpHeader.CACHE_CONTROL, "max-age=0");
request.header(HttpHeader.CONNECTION, "keep-alive");
request.header(HttpHeader.CONTENT_TYPE, "application/x-www-form-urlencoded");
request.header(HttpHeader.HOST, "www.example.com);
for (Map.Entry<String, String> entry : params.entrySet()){
request.param(URLEncoder.encode(entry.getKey(), "UTF-8"), URLEncoder.encode(entry.getValue(), "UTF-8"));
if(!StringUtils.isEmpty(content)){
content+="&";
}
content+=URLEncoder.encode(entry.getKey(), "UTF-8")+"="+URLEncoder.encode(entry.getValue(), "UTF-8");
}
request.header(HttpHeader.CONTENT_LENGTH, ""+content.length());
I see JSESSIONID and SLB_Cookie are present in the request. Since the website is out of our control I really can not track what is the issue.
Please help me to resolve this issue. Any pointers to resolve the issue on client side is appreciated. is there any way we can make sure which header causing this issue.
I solved the problem.
Issue with the form parameters value. I was sending encoded values where were encoded by jetty client again

Spotify App Strophe.js cannot connect to nginx/ejabberd combo

So I set up an ejabberd XMPP server and use nginx as a proxy on an EC2 instance. The Strophe.js echobot example can connect from my Chrome browser. Here are the Request Headers:
Request URL:http://foo.eu-west-1.compute.amazonaws.com/http-bind
Request Method:POST
Status Code:200 OK
Request Headers
Accept:*/*
Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3
Accept-Encoding:gzip,deflate,sdch
Accept-Language:de-DE,de;q=0.8,en-US;q=0.6,en;q=0.4
Connection:keep-alive
Content-Length:115
Content-Type:application/xml
Host:foo.compute.amazonaws.com
Origin:foo.eu-west-1.compute.amazonaws.com
Referer:foo.eu-west-1.compute.amazonaws.com/examples/echobot.html
User-Agent:Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.64 Safari/537.11
Request Payload
<body rid='2692151172' xmlns='http://jabber.org/protocol/httpbind' sid='15f6dc6cbc7a7d69b5db531c2ebf7828e094f043'/>
Response Headers
Access-Control-Allow-Headers:Content-Type
Access-Control-Allow-Origin:*
Connection:keep-alive
Content-Length:286
Content-Type:text/xml; charset=utf-8
Date:Fri, 04 Jan 2013 11:14:14 GMT
Server:nginx/1.2.4
I ported the echobot example to work in Spotify as an app. However, Strophe cannot connect. Here is the Web Inspector network log:
Request URL:http://foo.eu-west-1.compute.amazonaws.com/http-bind
Request Headers
POST http://foo.eu-west-1.compute.amazonaws.com/http-bind HTTP/1.1
Origin: sp://chatify
User-Agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.11 (KHTML, like Gecko) Chrome/17.0.963.15 Safari/535.11
Content-Type: application/xml
Request Payload
<body rid='790399813' xmlns='http://jabber.org/protocol/httpbind' to='ec2-54-246-45-111.eu-west-1.compute.amazonaws.com' xml:lang='en' wait='60' hold='1' content='text/xml; charset=utf-8' ver='1.6' xmpp:version='1.0' xmlns:xmpp='urn:xmpp:xbosh'/>
Now. The RequiredPermissons in the manifest.json look as follows:
"RequiredPermissons": [
"http://foo.eu-west-1.compute.amazonaws.com",
"foo.eu-west-1.compute.amazonaws.com",
"http://foo.eu-west-1.compute.amazonaws.com/http-bind",
"foo.eu-west-1.compute.amazonaws.com/http-bind"
]
I can load sources from foo.eu-west-1.compute.amazonaws.com so I think the permissons work.
The Spotify app uses a different origin, "sp://chatify". I read that this can cause problems. And Access-Control-Allow-Origin:* should be added to the header. I did so in the nginx config just to find out that it had been sent all along. You can see it in Response Headers of the first request.
Strophe.js itself says in the logs of the example if turned on:
error 0 happened
So any suggestions?
The manifest seems to be right
Access-Control-Allow-Origin;* seem right
It works in a browser but not Spotify.
Thx for your help!
Update:
If I open the echobot.html locally it still works. The Origin is then null.
Okay, I got it to work. And the solution is a classic. However, my debugging might help others.
At first I looked at the Web Inspector. It showed that all request were canceled. No the inspector is not always right as mentioned in many places. This time it was, though.
So Strophe.js could not establish a connection. To see if any custom Spotify App could establish a connection I tried the Google Maps example from the tutorial app. It did not work with the native Linux version and the Windows under wine. It did however work under windows.
My next step was to see if my app could load any resources from the net. So I simply added an iframe: . It did not load my page.
I took a close look at the manifest of the tutorial app and my app. I could not find any difference. So I just copied "RequiredPermissions" to see that I had a typo. Once that was fixed the iframe and eventually strophe.js worked.
It is funny. I looked for typos a few days ago I could not find any.
To sum up:
Make sure your server sets Access-Control-Allow-Origin;*
Set the Permissions. E.g.
"RequiredPermissions": [
"http://ec2-foo.eu-west-1.compute.amazonaws.com",
"ec2-foo.eu-west-1.compute.amazonaws.com",
"http://ec2-foo.eu-west-1.compute.amazonaws.com/http-bind",
"ec2-foo.eu-west-1.compute.amazonaws.com/http-bind"
]

XULRunner Application Request Header Information

I've developed a standalone XULRunner app that I'm using as a site-specific browser. The web application it accesses does filtering of browsers to know whether the browser being used is optimal. I'd like to add my XULRunner app to the list of optimal browsers. I figured that to do this, I'll need to know the HTTP header information that accompanies request sent by the XULRunner app. What information in the HTTP header can I use to identify my XULRunner app? Something like the Gecko Engine version, etc. I've been searching around, but no luck yet.
An application is usually identified by means of the User-Agent header. You can see it on the client side by means of the window.navigator.userAgent property, e.g. the header for Firefox 12 on Windows 7 is:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20100101 Firefox/12.0
The important part here is Gecko/... (identifies a Gecko-based browser) and rv:... (Gecko version). The Firefox/12.0 part should be replaced by something like MyApp/1.2.3 in your case (name and version number of your application).

context.Request.Files collection empty on remote server only

I'm using a custom ashx handler to handle a file upload. When run locally, the file uploads fine.
When I use the same setup on the web server I get a "Index out of range" error.
In firebug I see the binary contents of the file in the post data and the file name is also passed in the query string.
Any one seen this before?
I`m sure its something minor, but its driving me up the wall.
Update: Made some progress. I found out that I'm getting two different errors. One from FF / Chrome and one from IE. I'm focusing on FF now, just because firebug makes debugging easier. Now I get an error "Could not find a part of the path 'C:\inetpub\wwwroot\'"
Update 2: Got this working in FF/Chrome. Turns out IE and FF/Chrome post the data differentlly.
Update 3: Here is the output of the network profiler in IE dev tool:
Request header:
Key Value
Request POST /Secured/UploadHandler.ashx? HTTP/1.1
Accept text/html, application/xhtml+xml, */*
Referer http://cms.webstreet.co.il/Secured/fileUpload.aspx
Accept-Language he-IL
User-Agent Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)
Content-Type multipart/form-data; boundary=---------------------------7db13b13d1b12
Accept-Encoding gzip, deflate
Host cms.webstreet.co.il
Content-Length 262854
Connection Keep-Alive
Cache-Control no-cache
Request body:
-----------------------------7db13b13d1b12
Content-Disposition: form-data; name="qqfile"; filename="P-Art_Page_Digital.jpg"
Content-Type: image/jpeg
<Binary File Data Not Shown>
---------------------------7db13b13d1b12--
See the (big) list of comments and replies attached to the original question. Not sure why it works now, but Elad seems to have fixed his problem.
You have to specify the name tag.
<input id="File1" name="file1" type="file" />
I am pretty sure file uploads CANNOT be done via Ajax; you need to use a regular form post.
Also make sure you have the enctype attribute set correctly on your form tag.

Resources