I'm requesting a css file over HTTP from Chrome (Version 93.0.4577.63 (Official Build) (64-bit)).
The initial request looks like this:
As you can see, it has Cache-Control: no-cache in the request.
Doesn't this mean it first has to check with the server whether or not its version of the css file is up to date?
In which case it should get a 304 Not Modified (assuming the file hasn't been modified) on the next request?
Here's the request/response when I did a refresh of the page:
Why am I getting a 200 (from disk cache) and not a 304 Not Modified?
The issue is that some users of this website are getting an out of date version of the css file.
I suspect it's because the cached version is being returned before being revalidated with the server which is what I thought no-cache was meant to do.
Update:
I'm not sure why, but when I did refresh again, I got fewer headers in the request:
I didn't have the Disable cache button checked
Do you have the cache disabled in the devtools?
In Firefox, I get 304 only when the cache is not disabled.
I was checking the access logs for my site and found several of the following requests (site name, IP addresses, and other general info removed for clarity):
IP - - [Date/time] "POST / HTTP/1.0" 200 1815 "http://SITENAME.com//wp-admin/" "Browser"
IP - - [Date/time] "POST / HTTP/1.0" 200 1815 "http://SITENAME.com/wp-admin/" "Browser"
IP - - [Date/time] "POST / HTTP/1.0" 200 2761 - "Browser"
I don't have Wordpress installed and some of the referer URLs don't even seem valid (eg, "http://SITENAME.com//wp-admin"), but many have a successful status code (200) and data was transferred (seems to always be either 1,815 or 2,761 bytes).
I'm not concerned about someone accessing my site, I know odd access requests are normal and no strange files have appeared in my site directory. The requests are often followed by several failed attempts to access more specific Wordpress files.
What are they checking for and why is the check able to succeed?
I am currently doing some debugging on my website which involves calling the facebook API. I've installed dnsmasq to work with my mac os X to redirect all request to facebook.com to 127.0.0.1
This is my entry in dnsmasq.conf:
address=/facebook.com/127.0.0.1
I also have /etc/resolver/com with nameserver 127.0.0.1
When I turn dnsmasq on, visiting facebook.com will result in a PAGE NOT FOUND error in chrome. This shows that my dnsmasq is working.
However, I noticed that chrome will redirect http://www.facebook.com to https://www.facebook.com due to HSTS. I went on to chrome://net-internals#hsts to delete facebook.com's entry.
The strange thing is, when I am debugging, I see that facebook.com is indeed returning 307 redirects for http://www.facebook.com (See image)
This is very strange because the domain facebook.com is currently resolved to be 127.0.0.1 on my computer! Furthermore, when I dig more into the request, I do see that the request is valid:
Where is this 307 redirect coming from if facebook.com is unresolvable?
307 is an internal browser based redirect for HTTP Strict Transport Security (HSTS). It does not come from the server - it's a fake response created by the browser.
I have a wordpress blog in a VPS (Centos 6.8 x86) which some pages have a soundcloud embed. Whenever I try to view one of this pages, I receive a timeout error (http://prntscr.com/bpmm90).
GET
http://soundcloud.com/oembed
?maxwidth=0
&maxheight=0
&url=https%3A%2F%2Fsoundcloud.com%2F10de10%2Fsemana-dos-10-20-270616
&format=json
Operation timed out after 5000 milliseconds with 0 bytes received
Ok, I thought maybe I was doing something wrong in Wordpress, so I tried to 'wget' the same URL and... ERROR 500.
wget 'http://soundcloud.com'
--2016-07-06 18:46:01-- http://soundcloud.com/
Resolving soundcloud.com... 72.21.91.127
Connecting to soundcloud.com|72.21.91.127|:80... connected.
HTTP request sent, awaiting response... 500 Internal Server Error
2016-07-06 18:46:31 ERROR 500: Internal Server Error.
However, it all works fine if I try the same things on another server. I've already thought about if I was somehow blocked from accesing soundcloud through my VPS, but I barely did any call to the service.
The url in question is: http://soundcloud.com/oembed?maxwidth=0&maxheight=0&url=https%3A%2F%2Fsoundcloud.com%2F10de10%2Fsemana-dos-10-20-270616&format=json
Edit:
I tried this phpwebsocket: http://www.wilky.it/Shared/phpwebsocket.zip and it works in Firefox, but my question still remains: how do I get websockets to work with a php server in Chrome 17?
I'm following the tutorial here: http://net.tutsplus.com/tutorials/javascript-ajax/start-using-html5-websockets-today/
It appears as though the client connects, and then immediately disconnects. I noticed this error in the console:
Error during WebSocket handshake: 'Sec-WebSocket-Accept' header is missing
I'm trying it in Chrome 17.0.963.56 on my WAMP localhost with the php_sockets extension enabled.
I saw mentioned somewhere that Chrome had changed what it supported, but it didn't go in depth on how to fix it. I was hoping someone could step me through it. (I'm brand new to websockets).
Server:
{PATH}>php startDaemon.php
2012-02-20 07:02:51 System: Socket Resource id #7 created.
2012-02-20 07:02:51 System: Socket bound to localhost:8000.
2012-02-20 07:02:51 System: Start listening on Socket.
2012-02-20 07:03:01 WebSocket: Resource id #8 CONNECTED!
2012-02-20 07:03:01 WebSocket: Requesting handshake…
2012-02-20 07:03:01 WebSocket: Handshaking…
2012-02-20 07:03:01 WebSocket: Done handshaking…
2012-02-20 07:03:01 WebSocket: Resource id #8 disconnected!
Client:
Socket Status: 0
Socket Status: 3 (Closed)
I have the same problem (and I do not seem to be able to post a comment here, so I post a reply).
Actually, I just downloaded and tested phpwebsocket.
On safari 5.1.4, it works just fine.
On Chrome 17, I got the same error in the script log console:
Error during WebSocket handshake: 'Sec-WebSocket-Accept' header is missing
So, in websocket.class.php, I added to the header returned by server:
$accept = base64_encode(SHA1($key."258EAFA5-E914-47DA-95CA-C5AB0DC85B11"));
And I get the error:
Error during WebSocket handshake: Sec-WebSocket-Accept mismatch
Now, the header received by the server is:
GET /websocket/server.php HTTP/1.1
Upgrade: websocket
Connection: Upgrade
Host: localhost:12345
Origin: http://localhost:8888
Sec-WebSocket-Key: OqMJI0t/cOl6d6JNE+Op0g==
Sec-WebSocket-Version: 13
And the header sent back by the server is:
HTTP/1.1 101 WebSocket Protocol Handshake
Upgrade: WebSocket
Connection: Upgrade
Sec-WebSocket-Origin: http://localhost:8888
Sec-WebSocket-Location: ws://localhost:12345/websocket/server.php
Sec-WebSocket-Accept: ZjY5ODliNTViYzJlOTNkMjk4OTg3Y2U2NjQ3MTBlZjZiNzliYzk4Yg==
The Sec-WebSocket-Accept seems good, but still there is a mismatch error. Do you see a mistake somewhere? Maybe the protocol has changed to calculate the Sec-WebSocket-Accept, but I don't find it... Thanks for your help!
Edit: Here seems to be the solution (for me, at least): adding the parameter true to the SHA1 function, as found in files given in this issue thread. So, the Sec-WebSocket-Accept must be found like this:
$accept = base64_encode(SHA1($key."258EAFA5-E914-47DA-95CA-C5AB0DC85B11", true));
And, Sec-WebSocket-Key1 and Sec-WebSocket-Key2 does not seem to be present anymore in the client request, instead, $key must be extracted from the header: "Sec-WebSocket-Key".
New issue: It seems too that even if the web socket connection now works on the handshake, it disconnects when the first message is sent.
I noticed that in the console of Chrome 19:
A server must not mask any frames that it sends to the client.
Maybe this is the problem. It disconnects as soon as a message is sent. It works fine in Firefox.
I fixed this websocket problem and it works in chrome now.
First I used:
Then I used the encode function from:
https://github.com/lemmingzshadow/php-websocket
I fixed the replaced the encode function with the one in the connection.php file in lemmingzshadow’s github and it started working. The function is called: hybi10Encode in the \server\lib\WebSocket\connection.php file.
change this parameter in the function encode: $masked = true to $masked = false
An EASY way to fix is add Sec-WebSocket-Accept information when do_handshake, code as below:
list($resource,$host,$origin,$key) = $this->getheaders($buffer);
$accept = base64_encode(SHA1($key."258EAFA5-E914-47DA-95CA-C5AB0DC85B11", true));
$upgrade = "HTTP/1.1 101 Web Socket Protocol Handshake\r\n" .
"Upgrade: WebSocket\r\n" .
"Connection: Upgrade\r\n" .
"WebSocket-Origin: {$origin}\r\n" .
"WebSocket-Location: ws://{$host}{$resource}\r\n".
"Sec-WebSocket-Accept: " . $accept . "\r\n\r\n";
$this->handshakes[$socket_index] = true;
socket_write($socket,$upgrade,strlen($upgrade));
where,
$accept = base64_encode(SHA1($key."258EAFA5-E914-47DA-95CA-C5AB0DC85B11", true));
$key is Sec-WebSocket-Key got from $buffer, you can print_r($buffer) to have a look.
Hope this can solve your problem..