Re: [PATCH] Plain Surrogate/1.0 support
Amos Jeffries wrote: Robert Collins wrote: On Sun, 2010-02-07 at 00:52 +1300, Amos Jeffries wrote: According to the W3C documentation the Surrogate/1.0 capabilities and the Surrogate-Control: header are distinct from the ESI capabilities. This patch makes Squid always advertise and perform the Surrogate/1.0 capabilities for reverse-proxy requests. Full ESI support is no longer required to use the bare-bones Surrogate-Control: capabilities. A quick check though - is it still only enabled for accel ports? (It shouldn't be enabled for forward proxying). -Rob Yes. That restriction is still in effect. The substantial changes are removing the #if ESI from around the relevant bits of code, and altering the Surrogate-Capability text not to mention ESI unless ESI is also present. The new code is for stripping off Surrogate-Control as a scoped hop-by-hop header unless Surrogate-Capability has itself been explicitly received from upstream surrogates. This is done regardless of mode to cope with cases like client->surrogate->forward->server and client->forward->surrogate->forward->server and client->surrogate->surrogate->server Oops, sorry. No that is not done in any mode. ... but should be. Will fix for the commit. The remaining two issues that will need fixing one day are: requests arriving in a forward-proxy port and being redirected out to reverse-proxy peers due to their actual destination. These will not have surrogate advertised. The resulting object may or may not interfere with objects being stored by the surrogate-control. stripping out only the current instances surrogate-id bits from the control header and passing on just the remaining bits to upstream surrogates. This is not done, so there is some information leakage when upstream send surrogate-capability. Amos -- Please be using Current Stable Squid 2.7.STABLE7 or 3.0.STABLE23 Current Beta Squid 3.1.0.16
Re: [PATCH] Plain Surrogate/1.0 support
Robert Collins wrote: On Sun, 2010-02-07 at 00:52 +1300, Amos Jeffries wrote: According to the W3C documentation the Surrogate/1.0 capabilities and the Surrogate-Control: header are distinct from the ESI capabilities. This patch makes Squid always advertise and perform the Surrogate/1.0 capabilities for reverse-proxy requests. Full ESI support is no longer required to use the bare-bones Surrogate-Control: capabilities. A quick check though - is it still only enabled for accel ports? (It shouldn't be enabled for forward proxying). -Rob Yes. That restriction is still in effect. The substantial changes are removing the #if ESI from around the relevant bits of code, and altering the Surrogate-Capability text not to mention ESI unless ESI is also present. The new code is for stripping off Surrogate-Control as a scoped hop-by-hop header unless Surrogate-Capability has itself been explicitly received from upstream surrogates. This is done regardless of mode to cope with cases like client->surrogate->forward->server and client->forward->surrogate->forward->server and client->surrogate->surrogate->server The remaining two issues that will need fixing one day are: requests arriving in a forward-proxy port and being redirected out to reverse-proxy peers due to their actual destination. These will not have surrogate advertised. The resulting object may or may not interfere with objects being stored by the surrogate-control. stripping out only the current instances surrogate-id bits from the control header and passing on just the remaining bits to upstream surrogates. This is not done, so there is some information leakage when upstream send surrogate-capability. Amos -- Please be using Current Stable Squid 2.7.STABLE7 or 3.0.STABLE23 Current Beta Squid 3.1.0.16
Re: I need your help for my DESSERTATION (ME - Computer Engineering)
Dhaval Varia wrote: Dear Sir, I am Doing my *research In SQUID proxy* as a part of my post graduation* (Master of Engineering) *Just started.but dont have a specific direction so i can move ahed. *I need your help in following confusions :- * 1. What topic / Module (In Squid) i choose to start my research work ? 2. Where do I understand the module. 3. what initially i have to do? to start my work? *Please sir,I will be greatful for your help.* Thanks & Best Regards. Dhaval varia (9924343883) Greetings, It's nice to see more people interested in Squid. (cc'ing to squid-dev mailing list, where developer discussions take place) Did you have any ideas about what sort of thing you would be most interested in? The current developer focus for this year is (mostly) on preparing Squid 3.2 for better traffic scaling via SMP CPU support. Our planned architecture so far is described here: http://wiki.squid-cache.org/Features/SmpScale With Squid becoming multi-instance the most urgent project I'm looking for someone to create a daemon for reliable logging of data from N squid instances simultaneously to one log file. This daemon needs to open its own configurable socket for accepting connection requests from various Squid instances. On receiving a request it needs to receive the unique hostname from the Squid connecting and store it for optional configured pre-pending to every log line received via that TCP link. It needs to cope cleanly with sockets opening and closing at any time. Logging of many thousands of requests per second, ideally a minimum 10,000/sec per connected Squid instance. Maybe ignore the in-channel log rotate commands but rotate whenever the logs reaches a configurable size. A module internal to Squid will also need to be created to use the new helper. Derived from the src/log/ModUdp.* daemon but using TCP logging and setup as well. Possibly to a daemon running on a remote machine. Deadline would be mid-year 2010 for something testable. End of year for something hopefuly able to be committed for use. Interested? Amos -- Please be using Current Stable Squid 2.7.STABLE7 or 3.0.STABLE23 Current Beta Squid 3.1.0.16
Re: squid_kerb_auth logging patch
Reviewed and applied. tis 2010-02-09 klockan 19:20 + skrev Markus Moeller: > Hi Amos, > >Here are patched for squid 3.1 and squid 3-head to add ERROR, WARNING, > etc to the logging messages. > > > Regards > Markus
squid_kerb_auth logging patch
Hi Amos, Here are patched for squid 3.1 and squid 3-head to add ERROR, WARNING, etc to the logging messages. Regards Markus squid_kerb_auth-logging.patch Description: Binary data negotiate_kerberos_auth-logging.patch Description: Binary data
