Re: Question regarding ESI Implementation
On Fri, Sep 30, 2011 at 7:38 PM, Jan Algermissen wrote: > >> Theres no specific meta documentation that I recall. It should be >> pretty straight forward (but remember that squid is a single threaded >> non-blocking program - so its got to work with that style of >> programming). > > Ah, I did not yet know Squid had an async programming model. Even better. The > current ESI Implementation is non-blocking, too? Yup, for sure. -Rob
Re: [PATCH] SMP Caching: Core, IPC, Shared memory cache, and Rock Store
Hi, I'm running playground (based on uptodate trunk); it seems to be forgetting to shut down squid-coord and squid-disk processes. I don't know if these patches fix the issue, I'm just giving a headsup. Kinkie On Fri, Sep 30, 2011 at 7:22 AM, Alex Rousskov wrote: > On 09/07/2011 08:50 AM, Alex Rousskov wrote: >> On 09/07/2011 05:48 AM, Amos Jeffries wrote: > >>> > configure.ac: >>> > * rock store build conditions seem a bit out of sync with the intro >>> > documentation. The docs imply that rock will work with just blocking I/O >>> > without SMP mode. > >> Yes, you still need to have SMP _support_, even if SMP mode is off. I >> think we can relax or even remove that requirement. > >>> > The build checks requires that IpcIo and shm_open are supported simply >>> > to build it in. Could that be made to allow blocking-only builds with a >>> > configure-time check for IpcIo? > >>> > Don't let this block the merge. Just make it clear in the docs and add >>> > to the TODO list if it is. > >> Sounds good, we will work on it. > > Hi Amos, > > The series of 9 trunk patches posted by Dmitry yesterday (Subject: > "Make Rock work w/o SMP") make Rock Store build and work using Blocking > disk I/O when necessary. Even shared memory support is no longer > required to use Rock store in a non-SMP mode. Bugs notwithstanding, they > should address your concerns raised above. Please yell if we missing > something. > > The same patches may fix Squid bug 3361 (at least). > > > HTH, > > Alex. > -- /kinkie
Re: Adding a reset option to the session helper
On Thu, 2011-09-29 at 13:49 +0200, Henrik Nordström wrote: > tis 2011-09-27 klockan 07:32 +0100 skrev Andrew Beverley: > > > I'd like to find a way around this. The best way that I can think of is > > to add an option to the session helper, to specify a URL that must be > > present for the timeout to reset. This URL would then be contained in > > the "continue" button on the splash page. > > See the active mode which is intended for this kind of explicit session > start. Thanks Henrik. That looks spot on. > > The URL match is done using Squid acls. > Could you point me in the direction of how to do this please? Looking at the documentation for the external_acl_type it states that "any string specified in the referencing acl will also be included in the helper request line". Is that the way to achieve it? Something like this? external_acl_type session concurrency=100 ttl=3 %SRC /usr/lib/squid3/ext_session_acl -a -T 10800 -b /var/lib/squid/session.db acl existing_users external session acl aclname urlpath_regex -i a_url_that_must_be_clicked LOGIN deny_info http://nelsonwr.wardroom/announce.php?url=%s existing_users http_access deny !existing_users expiry (Sorry, I would just try it out myself, but I don't have a squid instance to hand, and I want to get this up and running as soon as I get back!) Thanks, Andy
Re: Adding a reset option to the session helper
On Fri, 30 Sep 2011 20:07:29 +0100, Andrew Beverley wrote: On Thu, 2011-09-29 at 13:49 +0200, Henrik Nordström wrote: tis 2011-09-27 klockan 07:32 +0100 skrev Andrew Beverley: > I'd like to find a way around this. The best way that I can think of is > to add an option to the session helper, to specify a URL that must be > present for the timeout to reset. This URL would then be contained in > the "continue" button on the splash page. See the active mode which is intended for this kind of explicit session start. Thanks Henrik. That looks spot on. The URL match is done using Squid acls. Could you point me in the direction of how to do this please? Looking at the documentation for the external_acl_type it states that "any string specified in the referencing acl will also be included in the helper request line". Is that the way to achieve it? Something like this? external_acl_type session concurrency=100 ttl=3 %SRC /usr/lib/squid3/ext_session_acl -a -T 10800 -b /var/lib/squid/session.db acl existing_users external session acl aclname urlpath_regex -i a_url_that_must_be_clicked LOGIN deny_info http://nelsonwr.wardroom/announce.php?url=%s existing_users http_access deny !existing_users expiry (Sorry, I would just try it out myself, but I don't have a squid instance to hand, and I want to get this up and running as soon as I get back!) Something like this... acl sessionLOGIN external session LOGIN acl sessionLOGOUT external session LOGOUT acl sessionIsActive external session When the LOGIN/LOGOUT ACLs are tested they perform their action on the session state. The ACLs leading up to them have to be crafted to avoid testing them at all unless you want LOGIN/LOGOUT to happen on that request acl clickedLoginURL urlpath_regex -i a_url_that_must_be_clicked http_access allow clickedLoginURL sessionLOGIN # http_access deny logout_conditions ... sessionLOGOUT http_access deny !sessionIsActive http_access allow ... deny_info http://nelsonwr.wardroom/announce.php?url=%s sessionIsActive Amos
Re: [MERGE] c++-refactor HttpHdrCc
On Thu, 29 Sep 2011 17:59:13 +0200, Kinkie wrote: On Thu, Sep 29, 2011 at 5:55 PM, Alex Rousskov wrote: On 09/29/2011 09:10 AM, Kinkie wrote: How about proceeding like this? This has already grown way past a "playground" or "refactoring" job (it changes some behaviour). We merge as-is, and then change the behaviour in a follow-up commit to trunk. Sounds good to me. Also, wouldn't that make the parser unnecessarily strict? Not sure what you mean. We got a malformed max-stale value. We have only two options when it comes to that value interpretation, I think: A1. Treat it as valueless max-stale. A2. Ignore it completely. Since valueless max-stale results in possibly very stale content being served to an unsuspecting client, I think #2 is much safer (and compliant with HTTP). You know way more than I do about this, so ok. BTW, we have three options when it comes to forwarding the malformed directive: B1. Forward our own valid directive. B2. Forward nothing. B3. Forward the malformed directive. While option B3 could be the best, it requires more parsing changes. Option B2 is much better than B1, IMO, and requires minimal changes. We currently implement A1 and B1. It is OK to treat this problem as outside your patch scope. I just hope the above summary will help somebody fix this later. Implementing B3 would be trivial, if we are allowed to just forward Cc directives as we received them (I didn't dare do it due to my lack of in-depth HTTP compliance knowledge). I will gladly do it as a followup patch as the other fix above. Do you agree? Sure, but I doubt correct B3 implementation would be trivial. It would be indeed relatively easy to forward a malformed max-stale directive "as is" using the "other" member, but if Squid then sets its own max-stale, then we would be forwarding two max-stales, which is not kosher. Similarly, if we gain some code to filter directives (e.g., using squid.conf ACLs), this simple B3 implementation would not filter malformed ones. It would be OK to ignore all these problems if we could somehow prevent new/future Squid code from bumping into them accidentally, but I cannot think of a neat way to do that. IMO, we should not attempt B3 and stick with B2 for now. B2 is trivial. Ok. If that's fine by you then I'll push ahead the merge of the currently-implemented feature set to this evening, and start working on A2 (B2 is a natural consequence of it). B2 is not a valid option AFAIK. HTTP does not offer the option A2 as you are discussing right now. Since we know the header we must either treat it as an option known (A1) or something unknown (A3). * A3 means we can ignore it for operational purposes (like A2), the natural result being B3. A1 means we have to decide betrween B1 or B3. Treating it as a known directive which has been extended with some unknown extension value (B3). Or as definitely malformed and invalid (B1). Amos
