Can pipelined responses span tcp segments?

[Dan Kegel <da...@kegel.com>]

I'm writing a load test client, and want to make sure I handle
pipelined requests right.  I installed Red Hat 8.0 and its Apache 2.0,
and made an html file that referenced all the .gif's in /icons.
Fetching that page with Mozilla, I do indeed observe pipelined requests
and responses.

I have seen pipelined requests in which a particular HTTP request header
line starts in one TCP segment and ends in another, but I have
not yet seen the same thing for HTTP response lines from Apache.
Does Apache 2.0 do anything special to prevent that (presumably
to avoid triggering bugs in clients that assume that HTTP response
lines aren't split across successive read()'s)?

Thanks,
Dan

Re: Can pipelined responses span tcp segments?

[Brian Pane <br...@cnet.com>]

On Sat, 2002-10-19 at 17:43, Dan Kegel wrote:
> I'm writing a load test client, and want to make sure I handle
> pipelined requests right.  I installed Red Hat 8.0 and its Apache 2.0,
> and made an html file that referenced all the .gif's in /icons.
> Fetching that page with Mozilla, I do indeed observe pipelined requests
> and responses.
> 
> I have seen pipelined requests in which a particular HTTP request header
> line starts in one TCP segment and ends in another, but I have
> not yet seen the same thing for HTTP response lines from Apache.
> Does Apache 2.0 do anything special to prevent that (presumably
> to avoid triggering bugs in clients that assume that HTTP response
> lines aren't split across successive read()'s)?

2.0 doesn't actively try to prevent this.  I think it's
just a side-effect of the output code doing a sendfile call
per response: for the second response in the pipeline, we
end up doing a new write+sendfile for the response header
and the content on Linux, or a new sendfilev for the header
and content on Solaris.  We could probably consolidate multiple
responses into a single packet (which could result in some
response headers spanning packet boundaries) if we mmap'ed
the response files and did a writev, but that would hurt
performance on some platforms.  A better alternative, I
suppose, would be to use sendfilev to write multiple responses
at once on Solaris, or keep the connection TCP_CORK'ed across
multiple sendfile calls on Linux.

Brian