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.
