[squid-users] What about http 1 must die?

NgTech LTD ngtech1ltd at gmail.com
Sun Aug 31 17:30:24 UTC 2025


Thanks Amos,

I know what squid and other web servers do already so it's weird for me to
hear http/x should die.
I won't say if it works don't touch it but even the most basic http service
I tried to write 5 years ago didn't had such flaws.

Also, many lb and forward proxy are resistant to the attacks this post
mentioned.
I am unsure on what services he used it against.

For now I still believe that squid stable is very advanced in it's level of
perfection compared to other pieces of code out there.

There are other questions like:
Can any ai write anything in either golang/python/rust which can compete
with squid?

What others think?

And I must say i gave some ai's the chance to write an icap helper logic
for youtube.... I still couldn't make it create something like what I wrote
10 years ago.
And, I am looking for some caching challenges :)

Eliezer



בתאריך יום א׳, 31 באוג׳ 2025, 20:16, מאת Amos Jeffries ‏<
squid3 at treenet.co.nz>:

> On 31/08/25 07:49, NgTech LTD wrote:
> > Hey,
> >
> > I have seen this research:
> >
> > https://portswigger.net/research/http1-must-die <https://
> > portswigger.net/research/http1-must-die>
> >
>
> I'm not sure I would call that research exactly. It is pretty much an
> enumeration of theoretical flaws in HTTP/1 which **might** occur
> assuming one of the HTTP agents is designed badly.
>
> I notice that proper implementation of HTTP security requirements closes
> off a number of issues listed there.
>
> For example; all mentioned issues with "obs-fold" (obsolete HTTP/1.0
> whitespace folding) in Content-Length headers are not a problem when one
> obeys the RFC7230 / RFC9112 requirement to either; replace obs-fold with
> a single SP **before** processing the headers, OR to respond with a
> connection error (404 status response and TCP RST) whenever it is
> received on HTTP/1.1 messages.
>
>
> > And was wondering how squid is handling such cases.
> >
>
> AFAICS, Squid has been around and been updated with workarounds and
> fixes for all of these cases (and many more pre-RFC9112 issues) as they
> were discovered.
>
> Today Squid has a rather strict parsing of input, with our "lenient"
> mode only tolerating the broken inputs when they are able to be fixed
> without causing more issues and essentially no behavior change.
>
>
> Not sure I would go as far as the "must die" argument quite yet. The
> HTTP/1 syntax still has a place as Human-readable display for any HTTP
> version. But yes, that time to stop sending it in communications is fast
> approaching. HTTP/2 had its 10 year birthday earlier this year!
>
>
> HTH
> Amos
>
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> https://lists.squid-cache.org/listinfo/squid-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20250831/40722ba1/attachment.htm>


More information about the squid-users mailing list