My understanding is that the defaults chosen are defensive in nature in terms of shielding the Origin servers. For example, blocking delete helps to protect Origin Servers from a possible DOS attack, as otherwise each and every delete request must be proxied across and could bring down the Origin.
- Sudheer > On Nov 3, 2016, at 7:21 PM, Jered Floyd <[email protected]> wrote: > > > Bryan, > > Unfortunately, I don't think I know enough about the cache use case to be > helpful here; I use ATS solely as a reverse proxy. > > It appears to me than many RESTful applications make use of the full suite of > HTTP verbs. GET/POST/PUT/DELETE are the CRUD primitives, and need to be > proxied from clients to origin servers unhindered. In the reverse-proxy use > case, I don't see how cache modifications can be an in-band operation, and > thus must be relayed to a service endpoint specifically on the proxy server. > How common is it for DELETE requests to be sent to ATS for cache control > reasons by the content owner, versus having items fall out due to expiry or > LRU replacement? > > RFC 7231 section 4.3.5 says, "The DELETE method requests that the origin > server remove the association between the target resource and its current > functionality," and also "Responses to the DELETE method are not cacheable. > If a DELETE request passes through a cache that has one or more stored > responses for the effective request URI, those stored responses will be > invalidated (see Section 4.4 of [RFC7234])." > > I haven't gone through it and RFC 7234 in detail, but that seems pretty clear > that client requests should be proxied, and that the cache should be > invalidated. (Perhaps only on a 2xx response?) > > As I said, I don't know how often DELETE is used for operational cache > management so this may not be practical, but it seems to me that blocking > certain methods (PUT, DELETE, etc) is wholly inappropriate in ATS' role as a > proxy server. Perhaps someone closer to the game can comment? (Should this > move to the dev list?) > > --Jered > > ----- On Nov 3, 2016, at 5:30 PM, Bryan Call <[email protected]> wrote: > The problem with not denying it by default is someone can come by and delete > objects out of the cache. Do you have any ideas on making this better? > Unfortunately origins like httpd will respond back with 200 responses on the > DELETE methods by default (using php in my test), so we can’t rely on the > origins response code to know if/when to delete the cached object. Right now > we don’t make sure the origin responses back with a 200 response before we > delete the object from cache. Maybe that should be changed? I am not an > expert on webdav, so any input would be helpful. > > -Bryan > > > > > On Nov 2, 2016, at 2:49 PM, Jered Floyd <[email protected]> wrote: > > > Sudheer, > > Aha! > > Thank you; that also resolves a long-standing issue I've had with CalDAV > entry modification. This is perhaps a questionable default... > > --Jered > > ----- On Nov 2, 2016, at 5:44 PM, Sudheer Vinukonda > <[email protected]> wrote: > The default traffic server install blocks DELETE method from anywhere outside > of the localhost. > > You can modify it as needed for your env. > > https://docs.trafficserver.apache.org/en/latest/admin-guide/files/ip_allow.config.en.html?highlight=ip_allow#ip-allow-config > > Thanks, > > Sudheer > > > > From: Jered Floyd <[email protected]> > To: [email protected] > Sent: Wednesday, November 2, 2016 2:37 PM > Subject: ERR_PROXY_DENIED on DELETE requests? (Grafana behind ATS) > > > Hello fellow ATS users, > > I just ran into a bit of a head-scratcher that I bet someone here knows the > answer to. > > I recently set up a Grafana install behind ATS 6.2.0, and have found that I > can't delete dashboards, un-star things, or anything else involving the > DELETE verb. When I access the origin server directly there are no problems. > When going through ATS, the operation results in a "403 Access Denied" in > the error popup. > > ATS logs show instances like: > 1478122046.588 0 [my client IP] ERR_PROXY_DENIED/403 198 DELETE http://[my > origin server]:3000/api/user/stars/dashboard/2 - DIRECT/- text/html > > Why is ATS refusing to proxy these requests? > > I'm going to go dig into the source right now but perhaps someone has a > quicker answer? > > Thanks, > --Jered > > > > >
