| Michael Wojcik 2005-12-13, 6:03 pm |
|
In article <4397734b@news.microsoft.com>, "NewBee" <pleasepostreply@dontemail.com> writes:
> Assuming HTTP 1.0, what happens if I issue a GET request for a web page and
> then before I receive any response back from the server I issue another GET
> request for a different web page. Will I get an error back from the server?
> Will the server ignore the second GET?
I assume you mean another request to the same server.
First, note it's largely irrelevant, for these purposes, whether an
HTTP client waits for the first response before sending the second
request. A TCP conversation is a full-duplex connection. If the
server ever does see the second request (see below), it's entirely
possible that will only happen after the server has sent the first
response, and so the server has no way of knowing whether the client
sent the second request before or after receiving the first response.
HTTP/1.0 (RFC 1945) did not provide for multiple requests in the same
conversation. In standard HTTP/1.0, the server closes the connection
after sending the response. It will never see the second request
from the client. There's a good chance the client will receive an
error from its TCP implementation, either while sending the second
request or while receiving a response, but there are cases where that
may not happen, and the second request simply disappears.
In short, the most likely result is that your client will get an error
from either a send or a receive; if you're using POSIX/SUS sockets,
errno would typically be ECONNRESET or EPIPE.
HTTP/1.1 (RFC 2616) standardized persistent connections and
"pipelining", which is the technical term (in HTTP) for sending a new
request before receiving the response from the previous one.
There were experimental, non-standard implementations of persistent
connections for HTTP/1.0. RFC 2616 discusses these early
implementations (19.6.2), and refers to the more extensive discussion
in the original HTTP/1.1 specification (RFC 2068, see 19.7.1).
However, the experimental HTTP/1.0 persistence feature required
explicit use of the "Connection: Keep-Alive" header field by the
client; if your client is not sending that header field, HTTP/1.0
persistence is moot. Also, neither RFC discusses pipelining with
HTTP/1.0 persistence, and since it was never standardized it's
entirely implementation-dependent anyway.
By the way, comp.protocols.tcp-ip is sometimes a better place to
ask questions regarding the HTTP protocol itself. comp.infosystems.
www.servers.misc more often deals with questions regarding specific
server implementations. That's not a hard-and-fast rule, but you
might get a faster answer to HTTP protocol questions in c.p.t-i.
--
Michael Wojcik michael.wojcik@microfocus.com
Today's Carnivore bait: Distracted by the Anthrax song, I let my bin,
laden with goods, crash into a bush.
|