[squid-users] Customize squid to make it understand malformed requests

[Amos Jeffries]

On 16/01/2017 9:03 p.m., Oğuz İsmail Uysal wrote:
> For a private reason, I want to customize squid version 3.5.12 the way I

Note: That is a long-ago obsoleted Squid version.

> stated above. For example I have customized it already to make it
> understand \r\n /\r\n instead of \r\n\r\n as request's end, (I know that
> this decreases the reliability of squid but I need.). By the way this

"reliability" has nothing to do with it. You are talking about
redesigning the fundamental definition of how a message is framed. In
direct violation of how the rest of the HTTP talking Internet communicates.
 <https://tools.ietf.org/html/rfc7230#section-3>

DO NOT do that.

> customization was kinda easy,

Of course, changing code is the easy part. Getting it right is much harder.

For example you seem to think that \r\n\r\n is the end of a request.

It is actually the MIME terminator and occurs at what the syntax defines
as the *middle* of an HTTP message frame - between the MIME and payload
sections.

The MIME section is a sub-frame within HTTP messages. It is optional
(either non-existing or empty) and may be used in any of the three major
HTTP message types.

Payload is a rare occurance on GET requests, which I suspect is where
your mistakes is coming from. But there is actually an implicit
Content-Length:0 header in GET requests making the payload section not
visible when looking at traffic.

Beyond that, mime sections are also used by several other protocols that
Squid implements. We re-use code for common protocol parsing so the code
you are changing probably affects _all_ of those protocols.


> now I want it to remove the characters after
> a spesific character in request uri, and to remove a spesific character
> which is placed at the end of all headers (before \r\n).

So what you actually have is your very own non-HTTP custom messaging
syntax. Please stop modifying Squid's HTTP parsing logics.

For a custom protocol (lets call it Foo for now) you should create your
own Foo namespace and one (or more) Foo::Parser classes that do the
message decapsulation in accordance with your protocols syntax.

You can inherit from or use an instance of the Http1::RequestParser if
you want to re-use some of its HTTP logics. But do not re-write the HTTP
logic to do non-HTTP things. Because, as I mentioned above there are
other protocols also re-using that same HTTP logic.


> Which source files
> I need to edit, do anyone know ? Or is there any link in which I can find
> references to source code which are related to request parsing ?
> 

The Squid developers can be contacted through the squid-dev mailing
list. This list is for network administrators to discuss and get help
*operating* Squid properly.

Amos