You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@trafficserver.apache.org by Jered Floyd <je...@convivian.com> on 2016/11/02 21:37:21 UTC
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
Re: ERR_PROXY_DENIED on DELETE requests? (Grafana behind ATS)
Posted by Sudheer Vinukonda <su...@yahoo.com>.
I don't believe ATS caches responses to POST by default (there's a setting to override it if someone needs it). Delete OTOH affects the cache as well as Origin.
I do agree with your view that (other than being slightly on the conservative side in terms of being vulnerable against DOS attacks), there's no strong technical reason to not allow DELETE by default. But, again, this is only a "default" and is modifiable. The awareness aspect of it in terms of documentation and/or ease of identifying/troubleshooting etc may probably need to be improved.
- Sudheer
> On Nov 4, 2016, at 12:05 PM, Jered Floyd <je...@convivian.com> wrote:
>
>
> 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 <bc...@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 <su...@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 <je...@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 <bc...@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 <je...@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 <su...@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 <je...@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
>
>
>
>
>
>
>
Re: ERR_PROXY_DENIED on DELETE requests? (Grafana behind ATS)
Posted by Jered Floyd <je...@convivian.com>.
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 <bc...@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
Re: ERR_PROXY_DENIED on DELETE requests? (Grafana behind ATS)
Posted by Bryan Call <bc...@apache.org>.
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 <su...@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 <ma...@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] <https://tools.ietf.org/html/rfc7234#section-4.4>)."
>>
>> 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 <ma...@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 <ma...@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 <ma...@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 <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 <ma...@convivian.com>>
>> To: users@trafficserver.apache.org <ma...@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 <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
>>
>>
>>
>>
>>
Re: ERR_PROXY_DENIED on DELETE requests? (Grafana behind ATS)
Posted by Sudheer Vinukonda <su...@yahoo.com>.
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 <je...@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 <bc...@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 <je...@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 <su...@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 <je...@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
>
>
>
>
>
Re: ERR_PROXY_DENIED on DELETE requests? (Grafana behind ATS)
Posted by Jered Floyd <je...@convivian.com>.
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 <bc...@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
Re: ERR_PROXY_DENIED on DELETE requests? (Grafana behind ATS)
Posted by Bryan Call <bc...@apache.org>.
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 <je...@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 <su...@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 <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 <je...@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
>
>
>
Re: ERR_PROXY_DENIED on DELETE requests? (Grafana behind ATS)
Posted by Jered Floyd <je...@convivian.com>.
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 <su...@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 <je...@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
Re: ERR_PROXY_DENIED on DELETE requests? (Grafana behind ATS)
Posted by Sudheer Vinukonda <su...@yahoo.com>.
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 <je...@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
Re: ERR_PROXY_DENIED on DELETE requests? (Grafana behind ATS)
Posted by Jered Floyd <je...@convivian.com>.
To clarify, no traffic is generated to the origin server so this is a response generated internally by ATS.
--Jered
----- On Nov 2, 2016, at 5:37 PM, Jered Floyd <je...@convivian.com> wrote:
> 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