One final (?) set of patches for 2.HEAD
Just a few more; HTCP logging http://www.squid-cache.org/bugs/show_bug.cgi?id=2627 ignore-must-revalidate http://www.squid-cache.org/bugs/show_bug.cgi?id=2645 Create request methods consistently http://www.squid-cache.org/bugs/show_bug.cgi?id=2646 Do override-* before stale-while-revalidate, stale-if-error http://www.squid-cache.org/bugs/show_bug.cgi?id=2647 -- Mark Nottingham m...@yahoo-inc.com
Re: One final (?) set of patches for 2.HEAD
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 We have another for HTCP accelerator mode. Jason will hopefully send. Mark Nottingham wrote: Just a few more; ... -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKA3uDJiSUUSaRdSURCNh0AJ9NmA74Cmi8F+Xcvwic0EjzxSy+7QCgio5h xSE0i0TIOpGu/zWsViGZqPw= =SsoU -END PGP SIGNATURE-
[PATCH] Bug 422: RFC 2616 Date header requirements
AFAICT the Date: header is already implemented on all generated pages
and ICAP processed pages.
This tests and enforces Date: on all outgoing replies as required.
I'm not certain this is the right place, it appears to be post-caching.
The RFC indicates the Date: should be enforced pre-caching. But was
unable to find a place of input cloning/processing after initial parse.
If anyone can point it out to me I will be grateful. There are other
processing needing it to be added there too.
Amos
=== modified file 'src/client_side_reply.cc'
--- src/client_side_reply.cc 2009-04-08 10:01:57 +
+++ src/client_side_reply.cc 2009-05-08 00:22:09 +
@@ -86,8 +86,9 @@
clientReplyContext::clientReplyContext(ClientHttpRequest *clientContext) : http (cbdataReference(clientContext)), old_entry (NULL), old_sc(NULL), deleting(false)
{}
-/* create an error in the store awaiting the client side to read it. */
-/* This may be better placed in the clientStream logic, but it has not been
+/** Create an error in the store awaiting the client side to read it.
+ *
+ * This may be better placed in the clientStream logic, but it has not been
* relocated there yet
*/
void
@@ -1199,10 +1200,12 @@
return result;
}
-/*
- * filters out unwanted entries from original reply header
- * adds extra entries if we have more info than origin server
- * adds Squid specific entries
+/**
+ * Generate the reply headers sent to client.
+ *
+ * Filters out unwanted entries and hop-by-hop from original reply header
+ * then adds extra entries if we have more info than origin server
+ * then adds Squid specific entries
*/
void
clientReplyContext::buildReplyHeader()
@@ -1228,6 +1231,7 @@
//if (request-range)
// clientBuildRangeHeader(http, reply);
+
/*
* Add a estimated Age header on cache hits.
*/
@@ -1278,7 +1282,17 @@
hdr-putStr(HDR_WARNING, tempbuf);
}
}
+}
+/* RFC 2616: Section 14.18
+ *
+ * Add a Date: header if missing.
+ * We have access to a clock therefore are required to amend any shortcoming in servers.
+ *
+ * NP: done after Age: to prevent ENTRY_SPECIAL double-handling this header.
+ */
+if ( !hdr-has(HDR_DATE) ) {
+hdr-insertTime(HDR_DATE, squid_curtime);
}
/* Filter unproxyable authentication types */
Re: [PATCH] Bug 422: RFC 2616 Date header requirements
Bundle Buggy has detected this merge request. For details, see: http://bundlebuggy.aaronbentley.com/project/squid/request/%3C4A037FD6.3080207%40treenet.co.nz%3E Project: Squid
Re: [RFC] MERGE: chunked-encoding patch for 3.0
Alex Rousskov wrote: On 05/03/2009 12:47 AM, Amos Jeffries wrote: The Gentoo project have back-ported the chunked-encoding changes from 3.1 to 3.0. Votes please on whether it should be merged into 3.0 officially or left as a patch? I've held off so far due to 3.0 being under freeze and 3.1 already available for those who need it. Also the amount of work needed to do this counted against. Alin brings up a good point though about other peoples views of stability being stricter despite their need of this being no less. With the work now being done I'm minded to apply if others agree. Ref: http://dev.gentoo.org/~mrness/distfiles/squid-3.0.14-chunk-encoding.patch.gz I've held off since 30 is stable Handling chunked messages is, essentially, a bug fix, although the bug is not in Squid. Production caches do see problems with broken HTTP clients and servers insisting on chunks. Since v3.1 will not become officially stable next week, we should probably apply this fix to relieve the pressure. If we do apply this, should we apply chunked _request_ support hack as well? That change is available as two 3.0 patches and has received some production testing (v3.1 and trunk port are almost done): http://bazaar.launchpad.net/~rousskov/squid/3p0-plus/revision/8899.1.27 http://bazaar.launchpad.net/~rousskov/squid/3p0-plus/revision/8937 Agreed. I'd would kind of rather see wider testing in trunk/3.1 before things go into 3.0. How close is the port to merge that? But if you believe the request bit has had sufficient testing already and can bring the branch up to the result after reply patching I will add to the chunked RC release for these over this weekend. Both can then have the full 8-week testing delay to STABLE16. Amos -- Please be using Current Stable Squid 2.7.STABLE6 or 3.0.STABLE14 Current Beta Squid 3.1.0.7
Re: [RFC] MERGE: chunked-encoding patch for 3.0
On 05/07/2009 07:11 PM, Amos Jeffries wrote: Alex Rousskov wrote: If we do apply this, should we apply chunked _request_ support hack as well? That change is available as two 3.0 patches and has received some production testing (v3.1 and trunk port are almost done): http://bazaar.launchpad.net/~rousskov/squid/3p0-plus/revision/8899.1.27 http://bazaar.launchpad.net/~rousskov/squid/3p0-plus/revision/8937 I'd would kind of rather see wider testing in trunk/3.1 before things go into 3.0. How close is the port to merge that? The trunk port is in the final polishing/testing stage and should be ready next week. But if you believe the request bit has had sufficient testing already and can bring the branch up to the result after reply patching I will add to the chunked RC release for these over this weekend. Both can then have the full 8-week testing delay to STABLE16. I am not pushing for a fast track commit of chunked requests hack to 3.0. If there is consensus that the hack should be committed to 3.0, I am totally fine with letting its port simmer in trunk and/or 3.1 until everybody is comfortable with committing the original 3.0 hack. Thank you, Alex.
adding content to the cache
I am looking for a way to manually add content to the cache. Is there an API to do that ? For example, I have the following file image.gif and I want to add it to the proxy cache so it can be served from there when needed. Laurent
