[PATCH] Http::MethodType upgrade

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Tue, 24 Jul 2012 14:31:17 +1200

[using "accessor" to mean class methods(), "method" to mean HTTP method
for clarity]

This patch is converting the METHOD_* enum into a class with accessors
to determine method string/image, idempotency, safety (as per RFC 2616
terminology).

  * creates the initial http/ directory and http/libsquid-http.la
library as per SourceLayout needs
   - libsquid-http is chosen to prevent symbols mistakes with libhttp
which may exist on some systems under the libhttp or http/libhttp name.

  * url.cc parsing switch cases used to split CONNECT are converted to
if-else syntax
   - not a major change, but worth mentioning since it is logic
alteration.

enum changes:

  * migrates _method_t to Http::MethodType and makes it a enum with
auto-generated strings array provided by the new library.

  * the enum list is extended to contain all methods in the HTTPbis WG
new method registry
  - documentation now references that registry and HTTPbis draft
document listing methods

HttpRequest class changes:

  * cacheable() changed to maybeCacheable() accessor
  - to reflect that it determines NON-cacheability with certainty, but
when returns TRUE it can still be overridden by Http Reply details
and/or local environment details.
  - updated to cache the complex calculation result.

HttpRequestMethod class changes:

  * The new isIdempotent() and isHttpSafe() accessors are altered
slightly from the original code to match the RFCs. The existing code
produces incorrect true/false values on some methods.

  * new accessor shouldInvalidate() which produces true if the request
method alone is enough to determine an RFC SHOULD invalidate condition.
  - purgesOthers() accessor is still present with the old behaviour, but
for better caching we should convert the code to using
shouldInvalidate()

  * new accessors respMaybeCacheable() which produces true if the
request method alone is enough to determine an RFC MAY cache condition.
  - replaces isCacheable() accessor which did not produce any certainty
as implied by the name, and was producing incorrect assessments anyway
for some methods.
  - it is more of a test whether *Squid* is known to be able to cache
the response to this method, than whether the RFC permit it.
  - There are several cases where it should produce true according to
the RFCs but isCacheable() was doing false due to bugs or missing
feature support. These cases are now documented with reasons and things
to test or fix before they can be made to return true.

  * the remainders of obsolete extension_methods directive code is
dropped

Global httpCachable(method) function dropped - replaced by
HttpRequest::maybeCacheable() accessor which does better cacheability
checks

... and there are a lot of METHOD_FOO -> Http::METHOD_FOO symbol-only
changes fluffing out the patch size.

I have managed to get this building on todays trunk, but have not yet
been able to run-test it. On the whole I expect there to be some
cacheability behaviour changes due to the improved
idempotency/safe/invalidation/cacheability accessors.

TODO: needs testing through co-advisor to check for RFC compliance
regressions.

Amos

Received on Tue Jul 24 2012 - 02:31:26 MDT

This archive was generated by hypermail 2.2.0 : Tue Jul 24 2012 - 12:00:04 MDT