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.
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
