For all the HTTP protocol gurus !

ikoonman

I am trying to figure out how a client (such as a browser) knows how to match up HTTP responses for each GET request over a single connection.

A web browser for instance will open a connection to a server, and using TCP, communicate with it using GET requests. The server then replies with data prefixed with HTTP response headers. I am curious to find out in easy terms what it does (as specified in RFC2616) to match up all the responses for various GET's.

I am not sure if the responses are dealt with sequentially for each GET sent. I've used apps such as HTTPLook and HttpWatch but it's not very revealing what goes on "behind the scenes."

Can anybody shed some light on this for me?

TIA

dazberry

If you are talking about keep-alive: connections the connection is simply a series of GETs and responses in sequence. Pipelined GETs should also be sequenced in order of the clump of GETs received.

D.

Mutant_Fruit

i think what he means is:

If my browser sends off 20 "get" requests (suppose i open four pages in four tabs simulaenously): How does the browser know where each reply's data should go to. How does the browser know that response 1 goes to tab 3, but response 15 goes to tab 1.

ikoonman

Mutant_Fruit wrote:

i think what he means is:

If my browser sends off 20 "get" requests (suppose i open four pages in four tabs simulaenously): How does the browser know where each reply's data should go to. How does the browser know that response 1 goes to tab 3, but response 15 goes to tab 1.

Close, but not quite I don't want to know over multiple "tabs" as in Firefox. It's more, when one html spawns multiple GET's to retrieve images and other objects for instance, how does it know which response from the server corresponds with which GET request?

Smoggy

A stab in the dark of an answer is :

Each get has a unique id generated , the reponse is then returned with this ID , matching the sent with the recieved gives you the coupling.

Maybe

ikoonman

Close, but no cigar.

Here are sample headers:

GET /trailers/ HTTP/1.1
Host: www.apple.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-gb,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
Cache-Control: max-age=0

Response:

HTTP/1.1 200 OK
Age: 176
Date: Sun, 14 May 2006 18:45:46 GMT
Content-Type: text/html
Expires: Sun, 14 May 2006 18:50:46 GMT
Cache-Control: max-age=300
Connection: close
Server: Apache/1.3.33 (Darwin) PHP/4.3.10
Cache-Control: private
Content-Encoding: gzip
Transfer-Encoding: chunked

Unfortunately no ID's

dazberry

ikoonman wrote:

It's more, when one html spawns multiple GET's to retrieve images and other objects for instance, how does it know which response from the server corresponds with which GET request?

If you're talking about concurrent requests, each request (or sequenced batch of requests) is using a different socket connection to the server. Even if multiple connections from the same client to the same server are open, they will have different port numbers on the client side. In general client-side port numbers are handed out automatically from a range.

192.168.0.10:24402 -> 192.168.0.1:80
192.168.0.10:24403 -> 192.168.0.1:80
etc.

So if the server sends GET1, 3 and 5 down 24402 - the server will in sequence respond with 1,3 and 5, but only back to 24402. If at the same time the client is also asking for GET2, 4 and 6 down 24403, the responses from the server will only come down that socket connection.

HTH

D.

ikoonman

That's it! Thanks. I knew it...... WHY didn't i think of this earlier?