Fwd: diff file for 302 loop bug when using storeurl
Was seen on info@, forwarded to squid-dev@ in case it's still relevant. Vidarebefordrat meddelande Från: chudy fernandez chudy_fernan...@yahoo.com Till: adr...@squid-cache.org Ämne: diff file for 302 loop bug when using storeurl Datum: Wed, 5 Nov 2008 08:04:48 -0800 (PST) I just wanna know if this has disadvantages. 302loopfixed.diff Description: Binary data
Remove URN support for 3.2 or 3.3?
Hi all, while working on string-fix I stumbled upon urn support code. There's quite a lot of it, but.. is anyone actually using it? URNs are a very nice idea, but it never really took off, and AFAIK it's not being used anymore. Such code is in high danger of bitrot, and even if not, is quite a burden to maintain as it's hard to test. My proposal is: - we ask on squid-users if anyone is using URNs now. Then, unless anyone speaks up, - we deprecate it in 3.2 - we remove it in 3.3 -- /kinkie
Re: Remove URN support for 3.2 or 3.3?
tor 2009-02-05 klockan 15:13 +0100 skrev Kinkie: while working on string-fix I stumbled upon urn support code. There's quite a lot of it, but.. is anyone actually using it? URNs are a very nice idea, but it never really took off, and AFAIK it's not being used anymore. As far as I know there is no one using the URN code. I vote for removal in 3.2 rather than spending time on fixing up the code, as long as urn: URIs is understood and can be forwarded to peers. Ideally we should in be able to forward pretty much any kind of URI to peers, not limited to URLs. Regards Henrik
Re: [MERGE] string-fix initial merge, take 2
tor 2009-02-05 klockan 12:08 +0100 skrev Kinkie: Hi all, here's a re-take of the string-fix initial merge. Compared to the retired first attempt it: - fixes the issues Tsantilas Christos found out about - implements String::find - some more users analyzed and fixed. For what's worth, I'm running this branch for my personal environment, and it hasn't bombed on me (yet). Looks nice. But there is still room for obvious improvement. strstr is pos(). -if (strstr (sctusable-content.buf(), ESI/1.0)) to +if (sctusable-content.pos(ESI/1.0)) String has a copy constructor -varState-feedData(unevaluatedVariable.buf(), unevaluatedVariable.size()); to + varState-feedData(unevaluatedVariable); -ESISegment::ListAppend (state.getOutput(), S.buf(), S.size()); could use a ListAppend method taking a String const argument to isolate this. Done at many places. return httpHdrExtFieldDoCreate( - f-name.buf(), f-name.size(), - f-value.buf(), f-value.size()); + f-name.rawBuf(), f-name.size(), + f-value.rawBuf(), f-value.size()); Same here... those are String but all this is further improvements along the same path. Regards Henrik
collapsed_forwarding and ICP
If I have a peer and it has collapsed_forwarding on, at what point will it return an ICP_HIT to me? E.g., 1) As soon as there's an outstanding (therefore collapsed) request for it? 2) As soon as there's a cacheable response in-flight for it? 3) Only when the entire response is in-cache? My reading of the code is that it's #1. Do I have this right? If that's the case: - On the plus side, this helps collapse requests across peers. - On the down side, it seems like there's the potential for requests to go to peers, only to find that the response is uncacheable. Thanks, -- Mark Nottingham m...@yahoo-inc.com
Re: collapsed_forwarding and ICP
fre 2009-02-06 klockan 10:07 +1100 skrev Mark Nottingham: If I have a peer and it has collapsed_forwarding on, at what point will it return an ICP_HIT to me? E.g., 1) As soon as there's an outstanding (therefore collapsed) request for it? 2) As soon as there's a cacheable response in-flight for it? 3) Only when the entire response is in-cache? My reading of the code is that it's #1. Do I have this right? Probably. If that's the case: - On the plus side, this helps collapse requests across peers. Yes. - On the down side, it seems like there's the potential for requests to go to peers, only to find that the response is uncacheable. Yes, and the slower the origin is to respond the more you'll see of this. Should be trivial to add a tuning knob to ICP for this. The not yet known if they may be cached objects have a special KEY_EARLY_PUBLIC flag set. See icpCheckUdpHit() for a suitable spot. htcpCheckHit would also need the same. Regards Henrik
Re: [MERGE] string-fix initial merge, take 2
On Thu, Feb 5, 2009 at 11:47 PM, Henrik Nordstrom hen...@henriknordstrom.net wrote: tor 2009-02-05 klockan 12:08 +0100 skrev Kinkie: Hi all, here's a re-take of the string-fix initial merge. Compared to the retired first attempt it: - fixes the issues Tsantilas Christos found out about - implements String::find - some more users analyzed and fixed. For what's worth, I'm running this branch for my personal environment, and it hasn't bombed on me (yet). Looks nice. But there is still room for obvious improvement. Ok, will do. If the current snapshot is acceptable, please merge despite there being room for those (and countless others, no doubt). Further improvements will be based upon this. -- /kinkie
Re: collapsed_forwarding and ICP
Thanks. I may have a look into putting those knobs in... On 06/02/2009, at 11:18 AM, Henrik Nordstrom wrote: fre 2009-02-06 klockan 10:07 +1100 skrev Mark Nottingham: If I have a peer and it has collapsed_forwarding on, at what point will it return an ICP_HIT to me? E.g., 1) As soon as there's an outstanding (therefore collapsed) request for it? 2) As soon as there's a cacheable response in-flight for it? 3) Only when the entire response is in-cache? My reading of the code is that it's #1. Do I have this right? Probably. If that's the case: - On the plus side, this helps collapse requests across peers. Yes. - On the down side, it seems like there's the potential for requests to go to peers, only to find that the response is uncacheable. Yes, and the slower the origin is to respond the more you'll see of this. Should be trivial to add a tuning knob to ICP for this. The not yet known if they may be cached objects have a special KEY_EARLY_PUBLIC flag set. See icpCheckUdpHit() for a suitable spot. htcpCheckHit would also need the same. Regards Henrik -- Mark Nottingham m...@yahoo-inc.com
Re: diff file for 302 loop bug when using storeurl
Shouldn't that be for 301, 303 and 307 as well? On 05/02/2009, at 8:54 PM, Henrik Nordstrom wrote: Was seen on info@, forwarded to squid-dev@ in case it's still relevant. Vidarebefordrat meddelande Från: chudy fernandez chudy_fernan...@yahoo.com Till: adr...@squid-cache.org Ämne: diff file for 302 loop bug when using storeurl Datum: Wed, 5 Nov 2008 08:04:48 -0800 (PST) I just wanna know if this has disadvantages. 302loopfixed.diff -- Mark Nottingham m...@yahoo-inc.com
Re: [MERGE] string-fix initial merge, take 2
Kinkie wrote: On Thu, Feb 5, 2009 at 11:47 PM, Henrik Nordstrom hen...@henriknordstrom.net wrote: tor 2009-02-05 klockan 12:08 +0100 skrev Kinkie: Hi all, here's a re-take of the string-fix initial merge. Compared to the retired first attempt it: - fixes the issues Tsantilas Christos found out about - implements String::find - some more users analyzed and fixed. For what's worth, I'm running this branch for my personal environment, and it hasn't bombed on me (yet). Looks nice. But there is still room for obvious improvement. Ok, will do. If the current snapshot is acceptable, please merge despite there being room for those (and countless others, no doubt). Further improvements will be based upon this. Accepted. And applied. FYI for anyone comitting additions these: I've assigned String NG: as the grouping prefix for this upgrade. Amos -- Please be using Current Stable Squid 2.7.STABLE6 or 3.0.STABLE13 Current Beta Squid 3.1.0.5
