Re: Various COSS minor problems
Hi, At 02.30 26/09/2006, Adrian Chadd wrote: On Sun, Sep 24, 2006, Guido Serassio wrote: > AioDone() now is called from StoreAufsDirDone() during squid shutdown > and calls squidaio_shutdown(). We must be sure that AioDone() is > executed once after both aufs and COSS shutdown. > I think that we could add a reference counter incremented after every > AioInit() call and decremented after any AioDone(). When the counter > is 0, AioDone is really executed. I'd just put it in the main shutdown code, after the filesystems have been flushed and shut down. Its much less pain. Then all you need is a check to make sure AioDone() only does its thing if AioInit() was called. Here a proposed patch using an usage counter. Thats my fault for introducing it. Just bump the log level up to debug(blah, 2) and it should go away? Done. Regards Guido - Guido Serassio Acme Consulting S.r.l. - Microsoft Certified Partner Via Lucia Savarino, 1 10098 - Rivoli (TO) - ITALY Tel. : +39.011.9530135 Fax. : +39.011.9781115 Email: [EMAIL PROTECTED] WWW: http://www.acmeconsulting.it/ coss.patch Description: Binary data
Re: proposal to remove port 563 from default ACLs
fre 2006-09-29 klockan 16:07 -0600 skrev Duane Wessels: > Our default ACL configuration allows CONNECT requests to port 563, > which is for NNTP over SSL. Assuming that nobody really uses NNTP > over SSL, especially through an HTTP proxy, I suggest that we > remove it from the defaults. I have actually used it in in real life. Was a some vendor support forum NNTP server requiring authentication and encryption to protect the passwords. But I have no problem with removing the port from the suggested default configuration as it's not at all common and easy to add back if needed. Most have switched to using web forums anyway.. This vendor actually provided both nntps and https access methods to the same forums. Unfortunately I don't remember the vendor, but it was one of the large commercial software vendors with active user communities. Regards Henrik signature.asc Description: Detta är en digitalt signerad meddelandedel
Re: squid-3 icap related patch
On Thu, 2006-09-28 at 05:18 -0400, Tsantilas Christos wrote: > Hi all, > > I am sending a small patch for icap client. > With this patch squid-icap works for me (using 1-2 clients). > I will test it more under load, using different scenarios. I am working on committing yours and other ICAP fixes to CVS. My goal is to make Squid3/ICAP pass Polygraph and real-world tests in a week or so. If you find other ICAP bugs, please post them here or add them to bugzilla. Thanks a lot for your patch, Alex.
Re: squid-3 icap related patch
On Thu, 2006-09-28 at 05:18 -0400, Tsantilas Christos wrote: > 3) File ICAP/ICAPModXact.cc function > ICAPModXact::handleCommWroteHeaders() > > Sometimes, we have read the headers but not any part of the body yet > so in this case we must not call writeMore() function. > > -writeMore(); > + if(virgin->data->body && virgin->data->body->contentSize()) > + writeMore(); As far as I can see, virgin->data->body is never NULL at this stage and the rest of the code assumes it is not NULL. Thus, I assume the first part of the above if-statement can be safely removed. This leaves us with the zero-size content part. I believe zero size content is valid. If writeMore() cannot handle it, writeMore() should be fixed and still called unconditionally in the above code. One place where zero-sized content is useful is for zero-size previews, which are common (please see below on that). > 7) File ICAP/ICAPModXact.cc function ICAPModXact::estimateVirginBody > > if function header->expectingBody(method, size) returns size==0 then > we do not expect a body. Can you explain why zero-size body should be treated differently here? I am especially worried about the case were Squid may tell the ICAP server that there was no HTTP entity body where in fact there was a body of zero length. The difference is likely to affect the adaptation logic on the ICAP server if the server adapts (or preserves) HTTP bodies. Again, if zero-size bodies cause problems elsewhere in the ICAP code, we should fix those problems, but hopefully without completely ignoring such bodies. > 8) File ICAP/ICAPModXact.cc function ICAPPreview::enable > > The theAd is the expected preview size so if theAd==0 do not > enable preview mode. > > -theState = stWriting; > +if(theAd >0) > + theState = stWriting; > +else > + theState = stDisabled; Zero-size Preview is very useful because it allows an ICAP server to receive the HTTP headers without the body before making any decisions. Why do you want to disable it? Do we have zero-preview handling bugs elsewhere? I believe I have applied all other changes you wrote about. The changes currently live on the squid3-icap branch in the SourceForge Squid repository. There are other ICAP bugs that must be fixed before ICAP code can be declared stable. I hope to nail most in the next week or so. I would appreciate if you can answer the above questions and/or provide your test cases so that we can "close" the three pending changes one way or the other. Thank you, Alex.
