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.
