trafficserver-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jered Floyd <je...@convivian.com>
Subject Re: ERR_PROXY_DENIED on DELETE requests? (Grafana behind ATS)
Date Fri, 04 Nov 2016 19:05:15 GMT
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 <bcall@apache.org> 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 < sudheervinukonda@yahoo.com >
>> 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 < jered@convivian.com > 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 < bcall@apache.org > 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 < jered@convivian.com >
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 < sudheervinukonda@yahoo.com
>>>>> > 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 < jered@convivian.com >
>>>>>> To: users@trafficserver.apache.org
>>>>>> 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

Mime
View raw message