I have inherited a large application and whenever an exception occurs I get a screen of gibberish in Chrome:
However in IE it shows the yellow screen of death as expected:
I can't figure out why this would even happen. Could it be an encoding problem?
Edit - Here are the request and response headers:
Request:
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8
Cache-Control:max-age=0
Connection:keep-alive
Cookie:.ASPXAUTH=5D3E8316B9AF0... [cut for brevity]
Host:localhost:81
Referer: **************** [intentionally hidden]
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.96 Safari/537.4
Response:
Cache-Control:private
Content-Length:6193
Content-Type:text/html; charset=utf-8
Date:Wed, 07 Nov 2012 16:42:15 GMT
Server:Microsoft-IIS/7.5
X-AspNet-Version:4.0.30319
X-Powered-By:ASP.NET
Try debugging this case with the Chrome Developer Tools (menu Tools -> Developer Tools). Switch to the Network tab and reload the page. Now click on the file name in the left column and check Headers -> Response Headers -> content-type for the value text/html as well as content-encoding for gzip. Maybe the response is compressed but this is not correctly declared in the http headers.
Also look into the Response tab. Is the content there a readable html document?
Related
How to perform button click, named: "confirm", using python 3.x and requests library? What parameters should be passed with POST request.
In general i am interested how to guess what settings are needed to achieve my point.
Here are headers information from the browser network graph (with slightly modified values):
General
Request URL:SOMEURL
Request Method:POST
Status Code:302 Found
Remote Address:SOMEADDR
Response Headers
Cache-Control:private
Content-Length:203
Content-Type:text/html; charset=utf-8
Date:Wed, 20 Apr 2016 05:54:51 GMT
Location:SOMELOCATION
MicrosoftSharePointTeamServices:14.0.0.6123
Server:Microsoft-IIS/7.5
SPRequestGuid:04e5403d-3170-4c1d-a5a3-441776ca4e57
X-AspNet-Version:2.0.50727
X-MS-InvokeApp:1; RequireReadOnly
X-Powered-By:ASP.NET
X-SharePointHealthScore:0
Request Headers
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding:gzip, deflate
Accept-Language:ru-RU,ru;q=0.8,en-US;q=0.6,en;q=0.4,ka;q=0.2
Cache-Control:max-age=0
Connection:keep-alive
Content-Length:3836
Content-Type:application/x-www-form-urlencoded
Cookie:filterValue=f4298401-b95c-4f84-b127-c1237f65819d; ASP.NET_SessionId=t35zomew310lpn45bgy1kp55; SectionId=15; databaseBtnText=0; databaseBtnDesc=0; Ribbon.ListItem=1366667|-1|655|1597680975; stsSyncAppName=Client; stsSyncIconPath=; Ribbon.ListForm.Display=808667|-1|503|815204513
Host:HOST
Origin:ORIGIN
Referer:REFERER
Upgrade-Insecure-Requests:1
User-Agent:Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.112 Safari/537.36
Query String Parameters
itemID:ID
List:LIST
activity:ACTION
workflowID:WFID
source:SOURCE
Form Data
MSOWebPartPage_PostbackSource:
MSOTlPn_SelectedWpId:
MSOTlPn_View:0
MSOTlPn_ShowSettings:False
MSOGallery_SelectedLibrary:
MSOGallery_FilterString:
MSOTlPn_Button:none
__EVENTTARGET:
__EVENTARGUMENT:
MSOSPWebPartManager_DisplayModeName:Browse
MSOSPWebPartManager_ExitingDesignMode:false
MSOWebPartPage_Shared:
MSOLayout_LayoutChanges:
MSOLayout_InDesignMode:
MSOSPWebPartManager_OldDisplayModeName:Browse
MSOSPWebPartManager_StartWebPartEditingName:false
MSOSPWebPartManager_EndWebPartEditing:false
_maintainWorkspaceScrollPosition:0
__REQUESTDIGEST:0x2D3C5B3A042C327D5B676EA782F2AB9623C1E03DD32F9884204134C32E8EB4287AB98B49EB235D3E27D0F8C0870E3F1CE69ABCDC2AB9C3797023D74CC1DC9AA9,20 Apr 2016 05:53:06 -0000
__VIEWSTATE:REMOVED
__VIEWSTATEGENERATOR:REMOVED
InputKeywords:Search this site...
ctl00$PlaceHolderSearchArea$ctl01$ctl03:0
ctl00$PlaceHolderMain$hiddRedirectURL:
ctl00$PlaceHolderMain$hidConfirm:checked
ctl00$PlaceHolderMain$hiddValidate:
ctl00$PlaceHolderMain$Button2:Confirm
__spText1:
__spText2:
I've inherited a website that contains about 100 audio files. The links to the files are relative links like this:
part 1
Back in the day those usually forced a download. Newer browsers now play the audio in browser. Except....
If the user comes to the site over https they are able to navigate the site and the html pages load, but the links to the audio files generate a 403 Forbidden error. Changing the protocol in the location http allows the mp3 to load and playback in the browser.
Why would the mp3 files be forbidden over https?
Is there a way to force the http protocol without having to make all the links absolute links? I notice the relative links "inherit" the protocol of the page they were loaded on. There isn't anything on any of these pages that need https so I wouldn't mind forcing all the parent pages to load over http....
This is a departmental site within a giant university. So I don't have access to the server, htaccess, or any of those kinds of tricks. All in browser, javascript, html solutions please.
UPDATE
I installed Firebug to view the headers and discovered that the audio plays fine in FireFox (on my mac). In Safari they load and play, but the controls don't show the progress or time, but they do play. And in Chrome they don't play at all.
I had also checked them on my PC at work and they don't play in IE9 (I know! Corporate IT, right?) or Chrome.
Here is what I get for headers in Firefox where the audio plays fine.
HTTP/1.1 200 OK
Date: Sat, 11 Apr 2015 15:39:04 GMT
Server: Apache
WWW: www3
Vary: X-Forwarded-Proto
Last-Modified: Tue, 16 Nov 2010 14:19:25 GMT
Etag: "78e935-d60ac-4952c3e68d540"
Accept-Ranges: bytes
Content-Length: 876716
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: audio/mpeg
GET /dept/area/language/stories/sounds/file.mp3 HTTP/1.1
Host: example.edu
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:33.0) Gecko/20100101 Firefox/33.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
Referer: https://example.edu/dept/area/language/stories.html
Cookie: _ga=GA1.2.829124232.1405280613; BIGipServerWWW-HTTP=1378527424.20480.0000; _gat=1
Connection: keep-alive
And these are what I get in Chrome.
Remote Address:128.122.119.202:443
Request URL:https://example.edu/dept/area/language/stories/sounds/file.mp3
Request Method:GET
Status Code:206 Partial Content
HTTP/1.1 206 Partial Content
Date: Sat, 11 Apr 2015 15:46:12 GMT
Server: Apache
WWW: www4
Vary: X-Forwarded-Proto
Last-Modified: Tue, 16 Nov 2010 14:19:12 GMT
ETag: "78e939-158dbc-4952c3da27800"
Accept-Ranges: bytes
Content-Length: 1
Content-Range: bytes 382271-382271/1412540
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: audio/mpeg
GET /dept/area/language/stories/sounds/file.mp3 HTTP/1.1
Host: www.nyu.edu
Connection: keep-alive
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_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.118 Safari/537.36
DNT: 1
Referer: https://example.edu/dept/area/language/stories.html
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8,es;q=0.6,hi;q=0.4,pt;q=0.2
Cookie: _ap_utmz=57748789.1416681263.3.1.utmccn=(direct)|utmcsr=(direct)|utmcmd=(none); _ap_utma=57748789.722895429.1387124094.1423327171.1425612794.7; __utma=57748789.194555315.1387124094.1423327171.1425612794.7; __utmz=57748789.1416681262.3.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); BIGipServerWWW-HTTP=1395304640.20480.0000; _gat=1; _ga=GA1.2.194555315.1387124094
Range: bytes=382271-382271
If-Range: "78e939-158dbc-4952c3da27800"
HTTP Request and Response Headers
Make sure to read about headers, mime types and content encodings.
You could try to utilise the Content-Disposition response header
An opportunity to raise a "File Download" dialogue box for a known MIME type with binary format or suggest a filename for dynamic content. Quotes are necessary with special characters.
Source: Wikipedia
Anyway your issue seems like a http header issue, could be compression as well. Take a look at your headers and whats different and troubleshoot from there. When you understood the problem, you can think of solutions.
Troubleshooting Tools
Use firebug or chrome developer tools to investigate. Fiddler Proxy to simulate different headers, since you have no access to your server.
File Permissions
Could be that SSL runs as another user or config on your server and the mp3 files have the wrong permissions or their parent directory. You need to check those, but since you have no server access you could be out of luck.
However, if SSL is not important to you just link to the files like so:
<a href="http://yourDomain.tld/folder/anotherFolder/file.mp3">
This will enforce the http protocol being used for the links. Most likely this results in the SSL chain being broken due to the mix in of http traffic into your ssl secured traffic. Therefore there's another alternative to achieve what you want:
Meta Refreshes
<meta http-equiv="refresh" content="3; URL=http://www.yourNonSSLDomain.tld/">
This will redirect to your non-SSL website where you can make sure to not mix https and http resources in your html document.
I've got an application where I'm using a text editor to insert images and banners etc. It gets the banner by calling an AJAX request to get the banner, then it compiles the JS.
I want a quick/easy way to cache the request. So I was hoping to just cache the response in the browser cache for 30 seconds.
So I'm trying to get it working in Chrome, but it keeps sending the request and the server keeps responding 200 Ok.
Here's the relevant part of my web config:
WebContentInterceptor webContentInterceptor = new WebContentInterceptor();
webContentInterceptor.setUseCacheControlHeader(true);
webContentInterceptor.setUseExpiresHeader(true);
webContentInterceptor.setUseCacheControlNoStore(true);
webContentInterceptor.setCacheSeconds(30);
registry.addInterceptor(webContentInterceptor);
And the cache control headers as per chrome:
Request URL:https://localhost:8443/admin/banners/json/by_shortcode/banner_test
Request Method:GET
Status Code:200 OK
Request Headersview source
Accept:*/*
Accept-Encoding:gzip, deflate, sdch
Accept-Language:en-US,en;q=0.8
Connection:keep-alive
Cookie:sidebar_closed=1; SPRING_SECURITY_REMEMBER_ME_COOKIE=UmljaGFyZC5HaWxsaW5nQGdtYWlsLmNvbToxNDIzODgzOTI1MTY4OmU1OGM2YzVjNjIwMWIyNWM3OTZlMWM5MThjMDc0MDg4; JSESSIONID=70842F221D3172686E406242AD3F5E02
Host:localhost:8443
Referer:https://localhost:8443/admin/pages/new
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.94 Safari/537.36
X-Requested-With:XMLHttpRequest
Response Headers
Cache-Control:max-age=30
Content-Type:application/json;charset=UTF-8
Date:Mon, 02 Feb 2015 14:03:13 GMT
Expires:Mon, 02 Feb 2015 14:03:43 GMT
Pragma:no-cache
Server:Apache-Coyote/1.1
Strict-Transport-Security:max-age=31536000 ; includeSubDomains
Transfer-Encoding:chunked
X-Content-Type-Options:nosniff
X-Frame-Options:DENY
X-XSS-Protection:1; mode=block
What I'm wondering is:
a) Why is the browser re-requesting the same request within the 30 second window? I am hoping to cache it for 30seconds.
Actually you tell the browser not to cache anything: Pragma:no-cache.
I am using express to write a response.
My code is:
res.set('Cache-Control', 'public, max-age=300');
res.send(data);
The headers I see are:
Remote Address:127.0.0.1:9000
Request URL:http://localhost:9000/some/path
Request Method:GET
Status Code:304 Not Modified
Request Headersview source
Accept:application/json, text/plain, */*
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8,he;q=0.6
Cache-Control:max-age=0
Connection:keep-alive
Cookie:express:sess=eyJ1c2VySWQiOiI1MzgxYTdjMDA0ZmIwMmIxMGI1NTdlZTMifQ==; express:sess.sig=lm-kq5ludtkWdRcFcVxNBL0BdT0
Host:localhost:9000
If-None-Match:W/"v9r1H7w4HiaXvycJ9FJ7lg=="
Referer:http://localhost:9000/
User-Agent:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36
Response Headersview source
access-control-allow-headers:Content-Type, X-API-KEY
access-control-allow-methods:GET, POST, DELETE, PUT
access-control-allow-origin:*
cache-control:public, max-age=300
connection:close
date:Sat, 03 Jan 2015 08:47:29 GMT
expires:Sat, 03 Jan 2015 08:52:29 GMT
etag:W/"v9r1H7w4HiaXvycJ9FJ7lg=="
x-powered-by:Express
However, I see my backend gets the request each and every time.
I have tried it with developers area open and closed and with "cache" on and off.
Nothing seems to actually cache the request
What am I doing wrong?
Here's an example JavaScript file request/response:
Request URL:http://local/index.js?time=1367958844038
Request Method:GET
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:en-US,en;q=0.8
Connection:keep-alive
DNT:1
User-Agent:Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31
Response Headers
cache-control:max-age=31536000
content-encoding:gzip
content-type:application/javascript
expires:Wed, 07 May 2014 20:34:04 GMT
last-modified:Tue, 07 May 2013 20:34:04 GMT
transfer-encoding:chunked
As you can see, the server responds with cache control, expires and even last modified, but everytime I reload with either F5 or clicking enter in location bar the request looks the same (I'd expect browser to send if-modified-since, etc.)
This happens in Chrome and Firefox at least.
Probably because the URL's time parameter changes with every request.
Since the URL is different, the browser can't use the previously cached response.