How does this differ from POST requests? POST is also an unsafe request method that requires cache invalidation.
Can I not remove a popular object by executing a POST request against it just as easily as a DELETE? --Jered ----- On Nov 4, 2016, at 2:38 PM, Bryan Call <[email protected]> wrote: > Yes, the main reason we block the DELETE method is to guard against a DOS > attack. Most people use ATS as a reverse proxy and rely on it to cache > responses. It would be very easy for someone to come along and remove popular > objects in cache repeatedly and DOS the proxy and origin servers. > I would have been open to allowing the DELETE method by default if origins > normally send back a non-200 response for DELETE method requests unless they > are strictly allowed to handle it, but that doesn’t seem to be the case. > -Bryan >> On Nov 3, 2016, at 7:47 PM, Sudheer Vinukonda < [email protected] > >> wrote: >> 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
