Messages in this thread | | | Date | Sun, 28 Jun 1998 19:46:33 -0700 (PDT) | From | Marc Slemko <> | Subject | Re: Thread implementations... |
| |
On Sun, 28 Jun 1998, Adam D. Bradley wrote:
> On Sun, 28 Jun 1998, Marc Slemko wrote: > > On Sun, 28 Jun 1998, MOLNAR Ingo wrote: > > > On 28 Jun 1998, Michael O'Reilly wrote: > > > > > > > Please reconsider this? There are some things that do a LOT of > > > > network-to-network copies (i.e. proxy servers), [...] > > > [...] > > > > > > nope, this is not how squid works. It wants a local copy of fetched > > > documents as well. So squid wants to use sendfile() this way: > > > > > > sendfile(outsidesocket,localfile); > > > sendfile(localfile,clientsocket); > > > > In addition to what other people have said about what squid does, remember > > that, in general, you normally don't want your proxy to buffer the entire > > file locally before it starts sending it to the client. That is horrible > > for large files over slow links. > > This is one of the unfortunate problems with HTTP/1.1 - it always > leans towards _semantic_transparency_, not _performant_transparency_. > Read RFC2068 section 13.8 (p.91); a compliant HTTP/1.1 proxy "MUST NOT > return a partial response to a client without explicitly marking it as > such using the 206 (Partial Content) status code." Which means a
No. Read the section; it refers to a "cache", not a proxy. It is only refering to what is done for future requests if it is cached, not for the initial response.
(yea, I'm smart but this one was easy because I could walk across the room and ask Roy Fielding)
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |