Closed Bug 1072412 Opened 10 years ago Closed 10 years ago

request send while awaiting SPDY push content after hard refresh

Categories

(Core :: Networking: HTTP, defect)

Product:
Core
Component:
Networking: HTTP
Version:
32 Branch
Platform:
x86_64
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1069724

People

(Reporter: amwebdk, Unassigned)

Details

(Keywords: access, Whiteboard: [spdy])

Attachments

(1 file)

The test server in node.js using node-spdy
1.71 KB, text/javascript
Details
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.122 Safari/537.36 Steps to reproduce: Consider this SPDY enabled website: <!DOCTYPE html> <link rel="stylesheet" href="/slow.css"> where slow.css is send using SPDY PUSH. Go to the site and do a hard refresh. The test server (in node.js using node-spdy) is attached. Actual results: 1) Firefox send a request for the main HTML page. 2) It then acknowledge the push stream for /slow.css. 3) It then requests /slow.css 4) Firefox uses the content it got from the request The test server output is: test server: https://localhost:8000 - Request for / send - push content send ! Request for slow.css send Expected results: 1) Firefox send a request for the main HTML page. 2) It then acknowledge the push stream for /slow.css. 3) Firefox uses the content it got from the push stream The test server output should be: test server: https://localhost:8000 - Request for / send - push content send
Keywords: access
Hardware: x86 → x86_64
Should properly reference the SPDY 3.1 draft > When a SYN_STREAM and HEADERS frame which contains an Associated-To-Stream-ID is received, the client must not issue GET requests for the resource in the pushed stream, and instead wait for the pushed stream to arrive. http://www.chromium.org/spdy/spdy-protocol/spdy-protocol-draft3-1#TOC-3.3.2-Client-implementation Also this is not an issue in Goole Chrome v37.
Whiteboard: [spdy]
thanks for the test case.. this is probably an artifact of a separate bug that we use a lot of separate connections on ctrl-shift-reload (In reply to Andreas Madsen from comment #1) > Should properly reference the SPDY 3.1 draft > > > When a SYN_STREAM and HEADERS frame which contains an Associated-To-Stream-ID is received, the client must not issue GET requests for the resource in the pushed stream, and instead wait for the pushed stream to arrive. > > http://www.chromium.org/spdy/spdy-protocol/spdy-protocol-draft3-1#TOC-3.3.2- > Client-implementation > > Also this is not an issue in Goole Chrome v37. I'm sure we can do better, but fyi hat's not actually a provision that can be honored 100% of the time so the server needs to be prepared to handle a pull for the same resource.. I say this because: 1] it assumes an infinite cache 2] it assumes the server can write whatever it wants into the cache without input from the client 3] it assumes the client MUST use a local cache entry instead of the network - which is never true 4] any enforceable interpretation of it needs to know whether the client read the associated-to before it generated the pull.. and that's just racy
Component: Networking → Networking: HTTP
I agree that caching in SPDY is a bit theoretical and unclear. But I don't really see this bug have anything to do with caching in the browser. The browser should just avoid making a request. Which is completely possible since SYN_STREAM frame should be send before the HTTP body.
the root issue here is connection handling in the presence of ctrl-shift-reload.. so track that under 1069724
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: