Re: Query regarding HTTP Request

On 04/10/2012 02:03 AM, Vinayak Samak wrote:

> Definitely I would like to work on this part.
> Please provide me starting point for the same.
> Whenever I will get time I will work on this and will be in touch with
> squid-dev team for problems/queries.

Hi Vinayak,

   Here is a subset of my header manipulation notes that are relevant to
your particular use case (as far as I can tell):

3. Add a new request_header_add squid.conf option

Add support for a new ACL­-driven squid.conf option that allows addition
of HTTP request header fields before the request is sent to the next
HTTP hop (a peer proxy or an origin server). The new header is added
after the client request is accepted and possibly adapted.

  request_header_add <field-name> <field-value> acl1 [acl2] ...

where

* Field­ name is a token specifying a supported (i.e., known to Squid)
HTTP header field name. Squid does not check whether the new header
conflicts with any existing headers or violates HTTP rules. If the
request to be modified already contains a field with the same name, the
old field is preserved but the header field values are not merged (more
advanced behavior can be implemented later, on top of these specs, but
is not needed for your use case).

* Field­ value is either a constant token or a quoted string. If a
quoted string format is used, then the surrounding quotes are removed
while escape sequences are processed, just like for the existing
"adaptation_meta" option.

* One or more Squid ACLs must be specified to restrict header insertion
to matching requests. As always in squid.conf, all ACLs in the option
ACL list must be satisfied for the insertion to happen. The
request_header_add option supports “fast” ACLs only.

To satisfy more advanced needs, the above needs to be extended to handle
custom (i.e., unknown to Squid) headers. I also have more sections like
these but they deal with deletion of custom headers and value macros
that are not relevant to your particular use case.

If the above minimum requirements are implemented (which is not
difficult), you can accomplish what [I think] you want by using a
combination of the new "request_header_add" and the existing
"request_header_access" options. For example:

  request_header_access User-Agent deny all
  request_header_add User-Agent "One Agent To Rule Them" all

Given Squid2 end of life status, I am only interested in adding the
above feature to Squid 3. Please let me know if you want to implement
the above for Squid3 trunk and we can coordinate.

Alternatively, you can port Henrik's external process code to Squid3.
Both the above and the port would require Squid Project review to get
officially accepted, of course.

Before you spend time implementing this or the external stuff, it may be
a good idea to discuss whether only one or both options can be accepted
if implemented correctly.

Thank you,

Alex.
Received on Fri Apr 13 2012 - 00:42:17 MDT