... is that Microsoft send out a good number of responses with a "Cache-Control: private" header. Any public cache storing these responses is in violation of RFC2616.
This posting from the squid-users mailing list sheds some more light on the issue.
If you were wanting to break the RFCs and were using squid, then you could probably modify src/http.c to return 1 for the relevant parts of the httpCachableReply function instead of 0, but that would be a "Bad Thing"(tm) when it came to RFC compliance.
The GPL doesn't need to be binding, as it removes restrictions that would normally be in place under copyright law. Most EULAs add in restrictions which are not covered by existing laws (yet).
This sounds like the solution ...
on
Undelete In Linux
·
· Score: 0, Redundant
One of the projects I'm involved in is the JANET Web Cache Service which is a top level proxy service for the UK academic community.
We use LVS code to load balance our squid boxen at layer 4, and have successfully shifted some 120Mbps through one of our nodes using direct routing on the backends, rather than NATing the system - this configuration barely loaded the frontend (which was only a 500MHz machine) and load balanced some 15-16 backend machines.
ISTR there is some early layer 5-7 code on the LVS site somewhere, but I've not used it, so I don't know how stable it is, or what the performance is like.
Be good for education and research though. JANET is planning to be 10Gbps on the core by late-Summer so they'll be pleased the standard has been approved (see http://www.ja.net/superjanet/index.html)
According to this document, ext3 supports three different journalling modes, including one where all data is written to the journal, rather than just the metadata.
Putting my medium-sized-mega-proxy-admin hat on (some 120 million reqs/day), I'd suggest that you don't use the source IP as part of your session key generation or implementation. Things break when remote hosts depend on the source IP remaining constant.
With more and more ISPs implementing proxy clusters and intercepting outbound traffic, this is a problem that is going to grow, rather than one which will go away.
If you insist on using the source IP as part of your session management, you might want to look at the HTTP_X_FORWARDED_FOR and HTTP_VIA headers, as these sometimes allow you to determine the original IP of the client before it hit the proxy. However, it's not failsafe - some ISPs anonymise the IP, and some proxies don't provide the headers. Where this information is provided, it is generally concatenated - so you can get the detail even where the user is passing through multiple proxies.
Nice to see UK academia got it right all those years ago.
... is that Microsoft send out a good number of responses with a "Cache-Control: private" header. Any public cache storing these responses is in violation of RFC2616.
This posting from the squid-users mailing list sheds some more light on the issue.
If you were wanting to break the RFCs and were using squid, then you could probably modify src/http.c to return 1 for the relevant parts of the httpCachableReply function instead of 0, but that would be a "Bad Thing"(tm) when it came to RFC compliance.
Nominet membership is a 400ukp one-off joining fee, and 100ukp annual subscription.
http://www.nic.uk/Members/HowToJoin/
The GPL doesn't need to be binding, as it removes restrictions that would normally be in place under copyright law. Most EULAs add in restrictions which are not covered by existing laws (yet).
... to this: askslashdot.
We use LVS code to load balance our squid boxen at layer 4, and have successfully shifted some 120Mbps through one of our nodes using direct routing on the backends, rather than NATing the system - this configuration barely loaded the frontend (which was only a 500MHz machine) and load balanced some 15-16 backend machines.
ISTR there is some early layer 5-7 code on the LVS site somewhere, but I've not used it, so I don't know how stable it is, or what the performance is like.
Be good for education and research though. JANET is planning to be 10Gbps on the core by late-Summer so they'll be pleased the standard has been approved (see http://www.ja.net/superjanet/index.html)
According to this document, ext3 supports three different journalling modes, including one where all data is written to the journal, rather than just the metadata.
See http://www.cisco.com/warp/public/701/20.html for some more information.
Putting my medium-sized-mega-proxy-admin hat on (some 120 million reqs/day), I'd suggest that you don't use the source IP as part of your session key generation or implementation. Things break when remote hosts depend on the source IP remaining constant.
/. do session management? ;-)
With more and more ISPs implementing proxy clusters and intercepting outbound traffic, this is a problem that is going to grow, rather than one which will go away.
If you insist on using the source IP as part of your session management, you might want to look at the HTTP_X_FORWARDED_FOR and HTTP_VIA headers, as these sometimes allow you to determine the original IP of the client before it hit the proxy. However, it's not failsafe - some ISPs anonymise the IP, and some proxies don't provide the headers. Where this information is provided, it is generally concatenated - so you can get the detail even where the user is passing through multiple proxies.
How does