Re: PAC serving

On 07/13/2010 07:02 PM, Henrik Nordström wrote:
> ons 2010-07-14 klockan 00:53 +0000 skrev Amos Jeffries:
>
>> Thats the plan. Those three objects I said we have to work with are the
>> parameters available to internalStart().
>
> My copy only have two parameters..
>
> internalStart(HttpRequest * request, StoreEntry * entry)
>
>> 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 would avoid that at this level. Needs too many shortcuts in the rest
> of the code..

I agree with Henrik.

And no, we are _not_ happy to have no adaptation for internally served
responses, but I would be surprised if you implement it: Squid has no
post-cache adaptation support right now so you will not be able to
piggyback to the existing code. It is all on the Server side and you are
probably working on the client_* side. In other words, we will not be
losing it. We just won't gain it :-).

On the other hand, if you make your code a child of the Server class,
then you will gain both caching and adaptation. Hmm... It actually
sounds like the best way forward, especially long-term! Do not intercept
internal requests until forward.cc and create your job there, as if it
is one of the Servers (serving "local file" protocol if you wish).

HTH,

Alex.
Received on Wed Jul 14 2010 - 21:48:09 MDT