The CCU API that this module currently does not support wildcard clearing, but the ECCU API does. It also has a SOAP interface (although quite different), so it's worth supporting IMO.
The current implementation adds support somewhat transparently by looking for a "*" in any of the paths, and if so, using the new AkamaiEnhancedCacheControlClient class instead. I'm not crazy about the way the patterns are translated into XML, but I'm not sure of a better way considering SimpleXML's lack of namespace support. I also had to do some goofyness when downloading the wsdl since for some reason the ECCU wsdl is behind basic auth and php is dumb.
Attached patch is still a bit rough, but I think it's 90% there. Will post a followup soon once I can test it a bit more.
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | akamai-eccu-support-1387298-8.patch | 8.62 KB | msonnabaum |
| #3 | akamai-eccu-support-1387298-3.patch | 8.02 KB | msonnabaum |
| #3 | akamai.cache_.inc_.txt | 957 bytes | msonnabaum |
| akamai-eccu-support.patch | 6.98 KB | msonnabaum |
Comments
Comment #1
febbraro commentedCool, I think this is good to support, that WSDL thing is so bogus :\ Do they support a REST API? or SOAP only?
As an aside, think we want to configure which API to use (on the config screen specify CCU or ECCU) or just do the smart recognition as you already are?
Comment #2
msonnabaum commentedUnfortunately it's SOAP only. I'm actually still having trouble with this, but working with akamai support to figure it out. Will post back again once I can confirm this is working.
I'm starting to think it's not worth it to try to be smart and maybe it should just be an option. Now that I've been digging into cachetags and using it with reverse proxy caches, I'm realizing there's a use case for invalidating based on other headers, which ECCU can do. For example, he's how I implemented it for purge: http://drupal.org/node/1394462.
Comment #3
msonnabaum commentedHere's a simpler version that's more flexible, but doesn't add anything else to the UI except the new end point url on the admin page. The only way to use the ECCU class is to call it directly, which I think is useful enough for other modules that we could just start it there. There are so many options in that API, and most of them are so edge case that I dont know if it's worth it to even try to put a UI in front of it.
So far the class can clear based on recursive path patterns and response headers. There are a few more options that could be implemented, but I figure they can be added as needed. I don't see all of them being useful in the case of Drupal, but I did it in such a way that they could be easily added later.
Also attached a cachetags backend as an example of how it could be used. Once the cachetags implementation starts to solidify, I'll submit a proper patch for it.
Comment #4
pwolanin commentedIs the WSDL common or somehow customized per akamai account? Seems odd indeed that it's behind auth.
Also, why not allow me to specify a path instead of a URL? If I've already downloaded the WSDL (and e.g. added it to my codebase), doesn't seem like I'd need to have the module downloading it again?
Comment #5
pwolanin commentedIf the name of the variable for the CCU WDSL path is changing, there needs to be an update function.
Comment #6
febbraro commentedThe WSDL is not specific per account, but it is not a commonly published URL. Akamai tries to keep it under wraps, so I could not publish it with the module (probably not a good idea either) In any case, the WSDL is a URI, but the SoapLibrary will (by default) cache it in the /tmp for 24 hours (the ttl and location are configurable), so it is really not making the WSDL request on each and every invocation. The URI is simply delegated directly to the SoapClient class, so if it supports local file URIs, then it should all work like magic.
Does that address your concerns?
Comment #7
msonnabaum commentedI think Peter was concerned because I have to bypass the default php handling of the wsdl cache because it's behind basic auth. Still, the patch only redownloads if it doesn't exist, so I dont see that as a problem.
Comment #8
msonnabaum commentedNew patch with an update function for the variable name change.
Comment #9
pwolanin commentedWe should never be downloading the WSDL. Put it on local disk with a setting to find it.
Comment #10
msonnabaum commentedSo we may not actually end up using this, because apparently, the ECCU api can take 20-40 minutes to propagate (vs 10 for CCU). That said, this patch worked fine for me when I tested it, and still might be useful to have even if it's not exposed in the UI.
The wsdl downloading is really a totally separate issue considering the CCU support already uses php's default behavior. If that's something we want to change, we should start a new issue. No sense in blocking this patch with it.
Comment #11
barrett commentedSince Akamai is sunsetting their CCU SOAP interface, I have a feeling this ECCU interface is being sunset as well. I've reached out to them for clarification.
Comment #12
heddnMarking this closed, since the SOAP interface has gone away.
Comment #13
barrett commentedActually, the SOAP interface has been removed from the module because the module is aimed at the CCU API, but we could re-add SOAP support to take advantage of the ECCU API.
Re-setting this to Postponed. I'm not averse to supporting the ECCU API, but its not priority at this point.
Comment #14
damienmckennaDoes the new v3 API support wildcard flushing?
Comment #15
damienmckennaLets re-enable this.
There are lots of scenarios where wildcard paths should be supported automatically, e.g. when there's a pager, when a Panels page's path includes arguments, etc.
Comment #16
damienmckennaFor sites that use Expire, they pass in a list of paths to clear and another list that indicates which of the first list should be wildcard flushes, it is up to the receiving module how to handle these. Currently the Akamai module just throws this extra information away and just processes the list of (internal) paths.
Comment #17
damienmckennaI've opened #2822616: Improve integration with hook_expire_cache to look to expanding support for the full hook_expire_cache() API, this would be a key part of it.
Comment #18
damienmckennaA slightly more.. silly.. approach would be to store all of the paths that need to be cleared and use logic in Drupal to push all of these paths through to Akamai. That would also result in faster cache clearing (Fast Purge vs ECCU).. but would mean storing a lot of data.
Comment #19
elijah lynnWildcard purge for v3 is coming but not yet available in Akamai yet. They are working on it and it was estimated to be Q4/Q1 a few months ago.
Comment #20
damienmckenna@Elijah Lynn: That's excellent news! Do you happen to have a link on where that may have been mentioned?
Comment #21
elijah lynnIt was internally from Akamai. Do you have access to an Akamai rep to request an updated timeline? I can ask if you don't.
Comment #22
WidgetsBurritos commentedPostponed pending #3244672: Seeking 7.x Maintainer