Guys, I've came across this problem I can't resolve myselg, I'm pretty sure I miss something pretty obvious, but that's usually how it is.
I'm developing my asp.net webapp in VS2008, XP SP3. When I want to debug, the asp.net starts the development server and the default browser associated with the vs2008 opens up and loads the page. In IE7 it loads the application, in FF3 I get :
connection failed (111) connection refused
This problem has just popped out this morning, after the restart of the computer (usually I just put it into a sleep mode) and until now it was working ok for both IE or FF. I can't think of anything that could have had changed since, there were no windows updates, just the antivirus, also I put the solution to SVN (but didn't do update on my end).
Any ideas?
Thanks heaps!
UPDATE:
from FF console:
Request headers
Host: localhost:3691
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.11) Gecko/2009060215 Firefox/3.0.11 (.NET CLR 3.5.30729)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: en,sk;q=0.8,cs;q=0.5,en-us;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Proxy-Connection: keep-alive
Referer: http://localhost:3691/CLIENT/Default.aspx
Cookie: tmTOCSaveStateCookie=undefined%2CRESOURCE_1; pmTOCSaveStateCookie=undefined
Pragma: no-cache
Cache-Control: no-cache
Response headers:
Server: squid/2.6.STABLE16
Date: Thu, 02 Jul 2009 08:32:21 GMT
Content-Type: text/html
Content-Length: 993
Expires: Thu, 02 Jul 2009 08:32:21 GMT
X-Squid-Error: ERR_CONNECT_FAIL 111
X-Cache: MISS from proxy.xyz.xyz
Via: 1.0 proxy.xyz.xyz:8080 (squid/2.6.STABLE16)
Proxy-Connection: close
I've tried to turn off firewall, antivirus but no luck. Has it got something to do with authentication?
Do FireFox and Internet Explorer have the same proxy settings ? FireFox doesn't use WinINet which most windows applications use.
I sometimes have the same happen to me when i'm inspecting HTTP traffic with Fiddler and my computer crashes although in that case its the other way around (IE/Chrome etc give me the error message and firefox works splendidly).
Related
This is a node webkit application that manages a bunch of webkit windows. Each webkit window uses signalR to connect to a MVC/webApi/signalR stack with no problems. Each window connects to 1-3 hubs over websockets. Everything works well.
My client wants to use SignalR inside the base node application that manages all the other windows. This is where things are getting 'interesting'...
So although the node app is running in a webkit environment it is served from the file system (header:origin=file://)
So i have started up signalR like (no JSONP as i'm targeting websockets)
app.Map("/signalr", map =>
{
map.UseCors(CorsOptions.AllowAll);
var hubConfiguration = new HubConfiguration();
map.RunSignalR(hubConfiguration);
});
So when i connect in the node app before the user logs into one of the windows spawned from Node, signalR connects over websockets fine, and i don't get any errors when they login(i.e. user has changed identity).
var connection = window.$.hubConnection("http://localhost");
connection.logging = true;
connection.start()
.done(function () { console.log('Now connected, connection ID=' + connection.id); })
.fail(function () { console.log('Could not connect'); });
the issue is i don't have the identity in the HubCallerConext serverside.
So if the user logs in first, then the node application has the cookies created in the other spawned window and this is where things get weird. SignalR fails to connect over websockets with the following error (from fiddler)
Unrecognized user identity. The user identity cannot change during an active SignalR connection.
Here is the negotiate call and then the failing call to connect (upgrade) over websockets.
I have a fiddler rule replacing Origin:file:// with localhost. just in case this was effecting it.
GET http://localhost/signalr/negotiate?clientProtocol=1.4&connectionToken=qs09pHGxr6x5fff1GJ%2FChWUnpSLX5ljV8FuS3h06P%2FhpS55cjNvh2uFHHTXukDI%2BK%2BcgsC6%2BWVJHba4xrkt6IVc2KwGIfm4eeyHrigNFRotjBYKb&connectionData=%5B%7B%22name%22%3A%22windowmanagementhub%22%7D%5D&_=1429572950768 HTTP/1.1
Host: localhost
Connection: keep-alive
Accept: text/plain, */*; q=0.01
X-DevTools-Emulate-Network-Conditions-Client-Id: 2E81759B-036D-4E92-ADF4-865AFBF59D2
User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.76 Safari/537.36
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Accept-Encoding: gzip, deflate
Accept-Language: en-GB,en-us;q=0.8,en;q=0.6
Cookie: ASP.NET_SessionId=opyggkqxnudnuag5mtxy40ai; __APPLICATION_LANGUAGE=en-GB; __RequestVerificationToken=eoB...GHjTo1; .ASPXAUTH=6909...82ED0; WindowsAuthCookie.LoginName=userName
Origin: http://localhost
and response
HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Transfer-Encoding: chunked
Content-Type: application/json; charset=UTF-8
Expires: -1
Server: Microsoft-IIS/8.5
Access-Control-Allow-Origin: http://localhost
Access-Control-Allow-Credentials: true
X-Content-Type-Options: nosniff
Date: Mon, 20 Apr 2015 23:46:49 GMT
177
{"Url":"/signalr","ConnectionToken":"LwJz6Ev3+9C/NbKBqHkrI8KwYaz53qiBbzDJVlcse1qRXU3loCqOI68kUb4kpyk8gdQlkKRJ0wBrpb+VVtUMFtrtSQOEhGQE9ZNaMDBajyK2/Evz","ConnectionId":"68e7751b-aaee-4ed7-aa36-a2d1ab25107f","KeepAliveTimeout":20.0,"DisconnectTimeout":30.0,"ConnectionTimeout":110.0,"TryWebSockets":true,"ProtocolVersion":"1.4","TransportConnectTimeout":5.0,"LongPollDelay":0.0}
0
then the following connect headers, which is the request that gets the 403
GET http://localhost/signalr/connect?transport=webSockets&clientProtocol=1.4&connectionToken=LwJz6Ev3%2B9C%2FNbKBqHkrI8KwYaz53qiBbzDJVlcse1qRXU3loCqOI68kUb4kpyk8gdQlkKRJ0wBrpb%2BVVtUMFtrtSQOEhGQE9ZNaMDBajyK2%2FEvz&connectionData=%5B%7B%22name%22%3A%22windowmanagementhub%22%7D%5D&tid=0 HTTP/1.1
Host: localhost
Connection: Upgrade
Pragma: no-cache
Cache-Control: no-cache
Upgrade: websocket
Origin: http://localhost
Sec-WebSocket-Version: 13
User-Agent:
Accept-Encoding: gzip, deflate
Accept-Language: en-GB,en-us;q=0.8,en;q=0.6
Sec-WebSocket-Key: HqfgeBw4svkTTpBK2CfaJA==
Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits
and the 403 response
HTTP/1.1 403 Forbidden
Cache-Control: no-cache
Pragma: no-cache
Transfer-Encoding: chunked
Content-Type: text/html
Expires: -1
Server: Microsoft-IIS/8.5
Access-Control-Allow-Origin: http://localhost
Access-Control-Allow-Credentials: true
X-Content-Type-Options: nosniff
Date: Mon, 20 Apr 2015 23:46:49 GMT
61
Unrecognized user identity. The user identity cannot change during an active SignalR connection.
0
Here is the javascript error in the console (from jquery.signalR 2.1.2, different connection ids, tokens)
WebSocket connection to
'ws://localhost/signalr/connect?transport=webSockets&clientProtocol=1.4&connectionToken=xzGshRPvF1XvGnq2S2nDmGZ3TISMGEt01Au0z9J%2FAfMa2OtQUMW5XX5HgW0I4n2MK5UfGfpJ4%2Fl7OkiRpQlSIFrDkfy25WHScwpkubBsn5403%2Ba3&connectionData=%5B%7B%22name%22%3A%22windowmanagementhub%22%7D%2C%7B%22name%22%3A%22browserloghub%22%7D%5D&tid=1'
failed: Error during WebSocket handshake: Unexpected response code: 403
SignalR will then (correctly) fall back to SSE and connect successfully. I can see the Identity of the user serverside.
I would really like to understand why i can't connect over websockets when the user is authenticated. If i delay ALL windows from connecting to the server via signalR until the user is authenticated then i also see the same behavior.
any help or clues would be greatly appreciated.
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.
hen a server replies to a HTTP GET request why doesn't it specify in say some new header, the GET request for which this response was generated?
GET /counter.gif HTTP/1.1
Host: www.subbu.org
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
HTTP/1.1 200 OK
Date: Mon, 19 Dec 2011 00:12:28 GMT
Server: Apache
Last-Modified: Thu, 08 Dec 2011 15:29:54 GMT
Accept-Ranges: bytes
Content-Length: 24523
Content-Type: image/png
**Get-request: /counter.gif**
This will help in case the requests are pipelined. The server can send the replies in the order they are generated and the browser can interpret what the reply is for. I know HTTP is stateless but this seems like a simple optimization. Why do you think it might be a problem to implement this?
Like that:
https://datatracker.ietf.org/doc/html/draft-nottingham-http-pipeline-00#section-5
?
If your using apache you may be referring to this functionnality: Trace
When trace is set to extended, it reflect the request body.
Regards
I have a web application running on Glassfish. The application is written in Java using Servlets.
The application allows you to upload files and get a direct link to that file.
For some reason, Safari and Chrome (possibly other browsers) have issues playing MP3 files (and other audio/video files) uploaded to this application.
An example uploaded MP3: http://uploads.graalcenter.org/upload/test.mp3
Sometimes, Safari will load the file and play it correctly, but most of the time it either stays on "Loading..." forever, or starts playing for a few seconds and then stops downloading it.
My browser is sending these request headers:
GET http://uploads.graalcenter.org/upload/test.mp3 HTTP/1.1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7) AppleWebKit/535.1+ (KHTML, like Gecko) Version/5.1 Safari/534.48.3
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Referer: http://uploads.graalcenter.org/info/test.mp3
Cache-Control: max-age=0
My server is responding with these response headers:
HTTP/1.1 200 OK
Date: Sun, 31 Jul 2011 02:02:03 GMT
X-Powered-By: Servlet/3.0 JSP/2.2 (GlassFish Server Open Source Edition 3.2-b06 Java/Sun Microsystems Inc./1.6)
Content-Length: 1137602
Server: GlassFish Server Open Source Edition 3.2-b06
Content-Type: audio/mpeg
Accept-Ranges: none
For comparison, I have uploaded the same file to an Apache server here.
The server responds with these headers:
HTTP/1.1 200 OK
Date: Sun, 31 Jul 2011 02:06:56 GMT
Connection: Keep-Alive
Content-Length: 1137602
Last-Modified: Sun, 31 Jul 2011 02:05:57 GMT
Server: Apache
Etag: "1aa08001-115bc2-4a953f48b6b40"
Content-Type: audio/mpeg
Accept-Ranges: bytes
Keep-Alive: timeout=2, max=100
The file plays correctly.
The only difference I can see is that my application does not accept range requests, but this shouldn't cause any issues, should it?
If I download the MP3 from my web application via curl, it has the same MD5 hash, so it's not corrupting the MP3 in any way.
Does anybody have any idea what might be causing the MP3 to not play correctly?
It seems like the problem was AppleCoreMedia, the plugin which handles audio, doesn't work correctly when not using range data. I wouldn't make the leap of blaming it on Apple, as it's entirely possible I made some mistake, but I ended up implementing the HTTP Range header and the it now works every time.
In Chrome and Safari a remote image included on my site never seems to get requested with caching-friendly headers (If-Modified-Since, etc) despite the server returning the appropriate information. Local resources, on the other hand, are requested with these headers. In contrast Firefox requests the remote resources with caching-friendly headers.
This is for images on S3 though I don't think it's unique to S3...
Update: Here's the actual request I'm seeing via Chrome Resources panel.
Request URL:http://mobtest.s3.amazonaws.com/4MKHZL-114.png
Request Method:GET
Status Code:200 OK
Request Headers
Accept:application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Cache-Control:max-age=0
Referer:http://mobtest.s3.amazonaws.com/4MKHZL-114.png
User-Agent:Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_4; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.86 Safari/533.4
Response Headers
Cache-Control:public, max-age=86400
Content-Length:4074
Content-Type:image/png
Date:Wed, 30 Jun 2010 12:15:42 GMT
ETag:"7e4739d5527ada6bb327f1e27ee656ef"
Last-Modified:Tue, 29 Jun 2010 13:40:08 GMT
Server:AmazonS3
x-amz-id-2:MKTS28Zu4zTsWFjXUTzvmRY214TO9LTKTxtgW1psWKa/JY2pnwmO9rxs8fyHd/O/
x-amz-request-id:F6047ADD0FD6D885
x-amz-version-id:O2OTsDbU4uKOwze7rbK_Do39U_Xhpnyp
Repeating the request doesn't lead to any additional headers being sent by Chrome (and as mentioned before, Safari). In contrast, quickly refreshing in Firefox gives me the following:
Status: 304 Not Modified
Response Headers
x-amz-id-2 IbhwfAP7FhIN7jtn2FrsjOkVZ8sIKJjv5llevKgw04y2xM+29GSFdGyQNXjiBaMY
x-amz-request-id 258F30A4CC2AC870
Date Wed, 30 Jun 2010 12:19:55 GMT
Cache-Control public, max-age=86400
Last-Modified Tue, 29 Jun 2010 13:40:08 GMT
x-amz-version-id O2OTsDbU4uKOwze7rbK_Do39U_Xhpnyp
Etag "7e4739d5527ada6bb327f1e27ee656ef"
Content-Type image/png
Content-Length 4074
Server AmazonS3
Request Headers
Host mobtest.s3.amazonaws.com
User-Agent Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7
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 300
Connection keep-alive
If-Modified-Since Tue, 29 Jun 2010 13:40:08 GMT
If-None-Match "7e4739d5527ada6bb327f1e27ee656ef"
Cache-Control max-age=0
Update 2: And now I see Chrome caching the content. Strange... I'm going to close this question and give Marc the answer.
If the server is sending back an "Expires" header that is somewhat far in the future, then the browser may be deciding that the content is still fresh enough in it's cache and that they don't even need to make a request to the server at all. You may want to review the headers being sent back from the server and ensure they are set to reasonable values. See ETag vs Header Expires for more information. Feel free to update your question with the actual URL or headers that are sent back from the server.