[squid-users] On what methods does url filtering needs to apply?

[Eliezer Croitoru]

Thanks for the insight.

You are right, it is not well defined.
I will try to rephrase or clear couple things.
Mainly content filtering is for offensive content.
This by definition is not the goal of a security related product that 
would not like to reveal the client attempts to reach the site using a 
HEAD request.
The main issue is about offensive content in the presentation layer.
Actually with squid it's not such a great issue but the main purpose of 
my question is to verify what would be allowed to be bypassed content 
filtering.
I will do more to clarify the issue.
A HEAD request will never include a body and will might contain 
offensive content in the HEADERS but it's not something that the user 
(unless he is an admin) will probably never see.
So a HEAD cannot ever contain a body response and there for might not 
require filtering.
A PUT request can contain a response body but it is not used and was not 
designed to send body content and else then that browsers do not really 
implement support for it.

Basically the main HTTP methods that are being used by browsers to 
retrieve content and present it are GET and POST.
I really have not seen a webpage that is built to work with PUT or 
OPTIONS only methods.
So an OPTIONS method blocking is something that might worth checking in 
a security environment but if the content filtering is to block abusive 
content then I probably do not need to invest time on an OPTIONS request.

So after defining that the main subject as abusive content in the body 
part of the message, POST and GET are a must to check but OPTIONS might 
not be required.

I must say as a side note that for small setups it might not really be a 
big of a difference but for large setups, if there is no real need to 
inspect the content then I can just reduce the delays for such requests 
by a few 100s ms.

The main reason I am asking this is due to the fact(not saying that they 
are right or wrong) that I have seen it being use in  the real world.
I have seen something like this:
icap_enable on
icap_service service_req reqmod_precache icap://127.0.0.1:1344/service
acl inspect_methods method GET POST CONNECT
adaptation_access service_req allow inspect_methods
adaptation_access service_req deny all

Thanks,
Eliezer

On 27/09/2015 20:58, Alex Rousskov wrote:
> Your question is impossible to answer correctly until you define
> "unwanted content". In other words, you need to define what you want to
> block (in general, non-HTTP terms) before it is possible to identify a
> subset of HTTP messages that can deliver the corresponding content. What
> is "desired" by some is "unwanted" by others, so we cannot guess what
> _your_  blocking objectives are.
>
> Alex.