Thanx for the both links it certainly useful on HTTP protocol structure...
unfortunatily, though, it doesn't have the part that I need most and that is
the mapping of the HTTP/1.0 request and
response structures onto the transport data units of the protocol such
as TCP... actually your first link restrictly says that this is not the
scope of this document but it doesn't give a refrence to the other
documents...
so I would appreciate if you can provide me with any other site/link that
you know of....


"Eugene Gershnik" <gershnik@hotmail.com> wrote in message
news:%23gle9dJtDHA.1888@TK2MSFTNGP10.phx.gbl...

ffarsif <ffarsif@hotmail.com> wrote:
Thus for HTTP, a TCP connection is opened, HTTP sends its request and the
server responds and so on, at some point the connection is closed.

The simplest case is a single request, where the browser has defined that it
doesn't want to use a Persistent Connection. This is then:
1. Client sends TCP SYN
2. Server sends TCP SYN+ACK
3. Client send TCP ACK
These three steps are the TCP "three-way handshake". The connection is now
open.
4. Client sends the HTTP Request in one or more TCP segments.
5. Server sends the HTTP Response in one or more TCP segments.
Obviously TCP ACKs the data segments in both directions.
6. Server closes (its side of) the TCP Connection (TCP FIN).
7. Client closes (its side of) the TCP Connection (TCP FIN). In fact, as
the client knows that it's not going to send another Request on this
connection, it can do this immediately after step 4.
And obviously again, ACKs are sent to acknowledge the FINs.

The delimiting of the Request and Response is defined in HTTP as TCP doesn't
do this, as noted it is just a stream of octets.
--
Alan J. McFarlane
http://homepage.ntlworld.com/alanjmcf/
Please follow-up in the newsgroup for the benefit of all.

Thanx for helping me....
I underestand the TCP/IP Client<-->Server transactions but I wasn't sure
about HTTP.... that's why I needed to know that, on the for example client
alone, if there is a request response going on between HTTP client and TCP
Client before TCP starts its transactions with the server...
If you say there is non and if I haven't been able to find any... then I
should belive you
So what you're saying is that all HTTP sees it's own request and respons
that comes back and it is completely blind or unaware about the underlying
TCP... On the other hand all TCP cares is to parse the header of HTTP to
find the Destiantion which to send the send the request to... Is this what
you're saying? Or is this argument correct? I need to know cuz I'm
developing LSP (Application-->Ws2_32.dll-->LSP-->Tcp.sys)

If for instance we don't have the LSP between the Ws2_32.dll and TCP.sys
(App-->Ws2_32.dll-->Tcp.sys) and the application is a TCP based application
(not a browser) then the client application code starts with
1.Socket Create
2.Socket bind
3.Socket Connect
4.Socket Send
who does these four calls in a HTTP-based application, is it browser?
Ws2_32.dll? or it is Tcp.sys?
Am I confused or am I confused
thank you...


"Alan J. McFarlane" <alanjmcf@yahoo.com.INVALID> wrote in message
news:EUuxb.561$Hy3.470@newsfep4-winn.server.ntli.net...

ffarsif wrote:

No this is not correct. TCP doesnt care about the overluying protocol.
TCP sends and receives data packets. This is simply a structure with
some header and the data of variable size. The destination and source
addresses are handled by the IP in TCP/IP. Even winsock is unaware of
http. Only the client and the server app know whats have to be done
with the received data. I don't know who (winsock or the underluying
tcp.sys) is responsible for splitting your client request to fit in the
packet size.

Any application that want to send data specify some own protocol. The
internet explorer knows HTTP and FTP. If you type in some address in
you browser the browser creates a socket. Then it binds the socket and
connect to the server. The browser send his request (ie. GET
/index.html) and waits for incoming data. The Server then sends the
data and disconnects. The application doesnt have to know anything
about the transportlayer - in this case tcp/ip.

HTH, Soeren

well thanx for the explanation, it helped.... Hopefully I'm clear by now...
I thank you all for taking the time to respond to my posting...

"Soeren Muehlbauer" <soeren.dd@gmx.de> wrote in message
news:bq6osc$1v89pj$1@ID-6627.news.uni-berlin.de...

TCP is not a message-oriented protocol and does not maintain the send
boundaries. The receiver only sees a stream of bytes, which is parsed, checked
to be a correct HTTP header, and executed. Then a response is printed to the
socket back.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

goch ya.... Is this a correct diagram?
-----------------------------------------------------------------------
| TCP Header | Data http://www.google.com/index.html/jpgfile.jpg |
-----------------------------------------------------------------------
by header I mean that www.google.com goes through the name resolution
interface of TCP... right?
I do underestand that it could be multiple packets....

"Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
news:uWJUc%23dtDHA.2308@TK2MSFTNGP11.phx.gbl...