(no subject)

On Tue, 13 Jul 2010 20:39:41 +0200, Henrik Nordström
<henrik_at_henriknordstrom.net> wrote:
> (10.48.23) amosjeffries: yeah. I'm looking at completing the
> requirements that were raised in the PAC serving audit.
> (10.49.19) amosjeffries: I have the initial bits re-worked. but am stuck
> not knowing which systems to link/create to do a non-blocking read and
> send of the file body.
> (10.49.52) amosjeffries: I think what I need is a BodyProducer, but not
> completely certain if thats right and when else needs to be created to
> use it.
> (10.50.02) amosjeffries: s/when/what/
> (10.51.13) amosjeffries: ... or even where it needs to plug into to get
> the client reading it
> (11.21.44) amosjeffries: hmm, looks like implementing a child off
> ServerStateData gets it into a shallower swamp.
> (12.37.04) amosjeffries: nope. dead ended. stuck with a client_fd,
> HttpRequest, and StoreEntry to work with.
>
> Not sure on the requirements, but PAC should just need static file
> serving right?
>
> The easiest would be to do the same as we do for icons, load the file
> statically in memory at startup and just some URL magic to lookup the
> right URL on access.

Easy, but a large memory hog if there are many files.
I'm expecting this to be picked up by those people who occasionally want
Squid to server whole HDD full of static data from the filesystem.

>
> The second is to implement it as part of the internal backend, starting
> off internalStart(). That's using the store interface for producing the
> data and is quite sane to work with.

Thats the plan. Those three objects I said we have to work with are the
parameters available to internalStart().
So far I have the else case of internalStart() doing stat() on the file
and generating the HttpReply headers. But doing async serving of the file
is muddy. I suspect if we are happy to loose caching and delay pools, ICAP,
eCAP, etc. etc then using sendfile() in non-blocking mode straight to the
client_fd would be fine.
 I left it with a simple AsyncJob comm reader which pushed data into the
StoreEntry and looped. Patch to follow when its had some error handling
added and been run-tested.

Amos
Received on Wed Jul 14 2010 - 00:53:21 MDT