Skip to content

Commit e4be173

Browse files
committed
2026-02-18
1 parent c9bc207 commit e4be173

23 files changed

Lines changed: 622 additions & 45 deletions

squid-dev/2026-February.txt

Lines changed: 43 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -35,3 +35,46 @@ best regards,
3535
An HTML attachment was scrubbed...
3636
URL: <http://lists.squid-cache.org/pipermail/squid-dev/attachments/20260218/daf7a215/attachment.htm>
3737

38+
From rousskov at measurement-factory.com Wed Feb 18 16:53:30 2026
39+
From: rousskov at measurement-factory.com (Alex Rousskov)
40+
Date: Wed, 18 Feb 2026 11:53:30 -0500
41+
Subject: [squid-dev] Architectural inquiry: Design rationale behind
42+
serialized request handling for identical URLs
43+
In-Reply-To: <GV2PR07MB116014F74F71B2E6A1C58D119E46AA@GV2PR07MB11601.eurprd07.prod.outlook.com>
44+
References: <GV2PR07MB116014F74F71B2E6A1C58D119E46AA@GV2PR07MB11601.eurprd07.prod.outlook.com>
45+
Message-ID: <6c0b53f8-7e71-4076-8f05-3eaffea872b7@measurement-factory.com>
46+
47+
On 2026-02-18 05:59, ????? ????? wrote:
48+
49+
> I am currently working on a research project involving request
50+
> dispatching and peer selection within the Squid-cache core.
51+
>
52+
> During my development, I have encountered several mechanisms and logic
53+
> blocks within the source code that deliberately prevent or queue
54+
> parallel HTTP requests for the same URL, effectively serializing them.
55+
56+
I do not think Squid does that by default. Either you are
57+
misinterpreting Squid code or you are looking at code related to
58+
collapsed_forwarding feature (see squid.conf.documented). That feature
59+
is off by default (and it queues but does not serialize parallel requests).
60+
61+
I recommend providing at least one specific code example to
62+
illustrate/substantiate your claim.
63+
64+
65+
HTH,
66+
67+
Alex.
68+
69+
70+
> I
71+
> would like to understand the fundamental design rationale behind these
72+
> restrictions. Specifically: Are these blocks in place due to specific
73+
> architectural constraints (such as memory management or Store Entry
74+
> state transitions)? Are there known side effects or risks I should be
75+
> aware of if I attempt to implement parallel requesting for identical
76+
> objects in a research environment? I want to ensure I fully understand
77+
> the system's design philosophy before proceeding with any modifications.
78+
> Thank you for your time and insights.
79+
80+

squid-dev/2026-February/009977.html

Lines changed: 6 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -13,7 +13,7 @@
1313
</style>
1414
<META http-equiv="Content-Type" content="text/html; charset=us-ascii">
1515

16-
16+
<LINK REL="Next" HREF="009978.html">
1717
</HEAD>
1818
<BODY BGCOLOR="#ffffff">
1919
<H1>[squid-dev] Architectural inquiry: Design rationale behind serialized request handling for identical URLs</H1>
@@ -24,7 +24,8 @@ <H1>[squid-dev] Architectural inquiry: Design rationale behind serialized reques
2424
<I>Wed Feb 18 10:59:33 UTC 2026</I>
2525
<P><UL>
2626

27-
27+
<LI>Next message (by thread): <A HREF="009978.html">[squid-dev] Architectural inquiry: Design rationale behind serialized request handling for identical URLs
28+
</A></li>
2829
<LI> <B>Messages sorted by:</B>
2930
<a href="date.html#9977">[ date ]</a>
3031
<a href="thread.html#9977">[ thread ]</a>
@@ -65,12 +66,14 @@ <H1>[squid-dev] Architectural inquiry: Design rationale behind serialized reques
6566
URL: &lt;<A HREF="http://lists.squid-cache.org/pipermail/squid-dev/attachments/20260218/daf7a215/attachment.htm">http://lists.squid-cache.org/pipermail/squid-dev/attachments/20260218/daf7a215/attachment.htm</A>&gt;
6667
</PRE>
6768

69+
6870
<!--endarticle-->
6971
<HR>
7072
<P><UL>
7173
<!--threads-->
7274

73-
75+
<LI>Next message (by thread): <A HREF="009978.html">[squid-dev] Architectural inquiry: Design rationale behind serialized request handling for identical URLs
76+
</A></li>
7477
<LI> <B>Messages sorted by:</B>
7578
<a href="date.html#9977">[ date ]</a>
7679
<a href="thread.html#9977">[ thread ]</a>
Lines changed: 91 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,91 @@
1+
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
2+
<HTML>
3+
<HEAD>
4+
<TITLE> [squid-dev] Architectural inquiry: Design rationale behind serialized request handling for identical URLs
5+
</TITLE>
6+
<LINK REL="Index" HREF="index.html" >
7+
<LINK REL="made" HREF="mailto:squid-dev%40lists.squid-cache.org?Subject=Re%3A%20%5Bsquid-dev%5D%20Architectural%20inquiry%3A%20Design%20rationale%20behind%0A%20serialized%20request%20handling%20for%20identical%20URLs&In-Reply-To=%3C6c0b53f8-7e71-4076-8f05-3eaffea872b7%40measurement-factory.com%3E">
8+
<META NAME="robots" CONTENT="index,nofollow">
9+
<style type="text/css">
10+
pre {
11+
white-space: pre-wrap; /* css-2.1, curent FF, Opera, Safari */
12+
}
13+
</style>
14+
<META http-equiv="Content-Type" content="text/html; charset=us-ascii">
15+
<LINK REL="Previous" HREF="009977.html">
16+
17+
</HEAD>
18+
<BODY BGCOLOR="#ffffff">
19+
<H1>[squid-dev] Architectural inquiry: Design rationale behind serialized request handling for identical URLs</H1>
20+
<B>Alex Rousskov</B>
21+
<A HREF="mailto:squid-dev%40lists.squid-cache.org?Subject=Re%3A%20%5Bsquid-dev%5D%20Architectural%20inquiry%3A%20Design%20rationale%20behind%0A%20serialized%20request%20handling%20for%20identical%20URLs&In-Reply-To=%3C6c0b53f8-7e71-4076-8f05-3eaffea872b7%40measurement-factory.com%3E"
22+
TITLE="[squid-dev] Architectural inquiry: Design rationale behind serialized request handling for identical URLs">rousskov at measurement-factory.com
23+
</A><BR>
24+
<I>Wed Feb 18 16:53:30 UTC 2026</I>
25+
<P><UL>
26+
<LI>Previous message (by thread): <A HREF="009977.html">[squid-dev] Architectural inquiry: Design rationale behind serialized request handling for identical URLs
27+
</A></li>
28+
29+
<LI> <B>Messages sorted by:</B>
30+
<a href="date.html#9978">[ date ]</a>
31+
<a href="thread.html#9978">[ thread ]</a>
32+
<a href="subject.html#9978">[ subject ]</a>
33+
<a href="author.html#9978">[ author ]</a>
34+
</LI>
35+
</UL>
36+
<HR>
37+
<!--beginarticle-->
38+
<PRE>On 2026-02-18 05:59, &#1500;&#1497;&#1488;&#1493;&#1512; &#1489;&#1512;&#1488;&#1493;&#1503; wrote:
39+
40+
&gt;<i> I am currently working on a research project involving request
41+
</I>&gt;<i> dispatching and peer selection within the Squid-cache core.
42+
</I>&gt;<i>
43+
</I>&gt;<i> During my development, I have encountered several mechanisms and logic
44+
</I>&gt;<i> blocks within the source code that deliberately prevent or queue
45+
</I>&gt;<i> parallel HTTP requests for the same URL, effectively serializing them.
46+
</I>
47+
I do not think Squid does that by default. Either you are
48+
misinterpreting Squid code or you are looking at code related to
49+
collapsed_forwarding feature (see squid.conf.documented). That feature
50+
is off by default (and it queues but does not serialize parallel requests).
51+
52+
I recommend providing at least one specific code example to
53+
illustrate/substantiate your claim.
54+
55+
56+
HTH,
57+
58+
Alex.
59+
60+
61+
&gt;<i> I
62+
</I>&gt;<i> would like to understand the fundamental design rationale behind these
63+
</I>&gt;<i> restrictions. Specifically: Are these blocks in place due to specific
64+
</I>&gt;<i> architectural constraints (such as memory management or Store Entry
65+
</I>&gt;<i> state transitions)? Are there known side effects or risks I should be
66+
</I>&gt;<i> aware of if I attempt to implement parallel requesting for identical
67+
</I>&gt;<i> objects in a research environment? I want to ensure I fully understand
68+
</I>&gt;<i> the system's design philosophy before proceeding with any modifications.
69+
</I>&gt;<i> Thank you for your time and insights.
70+
</I>
71+
</PRE>
72+
73+
<!--endarticle-->
74+
<HR>
75+
<P><UL>
76+
<!--threads-->
77+
<LI>Previous message (by thread): <A HREF="009977.html">[squid-dev] Architectural inquiry: Design rationale behind serialized request handling for identical URLs
78+
</A></li>
79+
80+
<LI> <B>Messages sorted by:</B>
81+
<a href="date.html#9978">[ date ]</a>
82+
<a href="thread.html#9978">[ thread ]</a>
83+
<a href="subject.html#9978">[ subject ]</a>
84+
<a href="author.html#9978">[ author ]</a>
85+
</LI>
86+
</UL>
87+
88+
<hr>
89+
<a href="https://lists.squid-cache.org/listinfo/squid-dev">More information about the squid-dev
90+
mailing list</a><br>
91+
</body></html>

squid-dev/2026-February/author.html

Lines changed: 9 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -19,10 +19,15 @@ <h1>February 2026 Archives by author</h1>
1919
</a></b></li>
2020
</ul>
2121
<p><b>Starting:</b> <i>Wed Feb 18 10:59:33 UTC 2026</i><br>
22-
<b>Ending:</b> <i>Wed Feb 18 10:59:33 UTC 2026</i><br>
23-
<b>Messages:</b> 1<p>
22+
<b>Ending:</b> <i>Wed Feb 18 16:53:30 UTC 2026</i><br>
23+
<b>Messages:</b> 2<p>
2424
<ul>
2525

26+
<LI><A HREF="009978.html">[squid-dev] Architectural inquiry: Design rationale behind serialized request handling for identical URLs
27+
</A><A NAME="9978">&nbsp;</A>
28+
<I>Alex Rousskov
29+
</I>
30+
2631
<LI><A HREF="009977.html">[squid-dev] Architectural inquiry: Design rationale behind serialized request handling for identical URLs
2732
</A><A NAME="9977">&nbsp;</A>
2833
<I>&#1500;&#1497;&#1488;&#1493;&#1512; &#1489;&#1512;&#1488;&#1493;&#1503;
@@ -31,8 +36,8 @@ <h1>February 2026 Archives by author</h1>
3136
</ul>
3237
<p>
3338
<a name="end"><b>Last message date:</b></a>
34-
<i>Wed Feb 18 10:59:33 UTC 2026</i><br>
35-
<b>Archived on:</b> <i>Wed Feb 18 11:17:58 UTC 2026</i>
39+
<i>Wed Feb 18 16:53:30 UTC 2026</i><br>
40+
<b>Archived on:</b> <i>Wed Feb 18 16:53:32 UTC 2026</i>
3641
<p>
3742
<ul>
3843
<li> <b>Messages sorted by:</b>

squid-dev/2026-February/date.html

Lines changed: 9 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -19,20 +19,25 @@ <h1>February 2026 Archives by date</h1>
1919
</a></b></li>
2020
</ul>
2121
<p><b>Starting:</b> <i>Wed Feb 18 10:59:33 UTC 2026</i><br>
22-
<b>Ending:</b> <i>Wed Feb 18 10:59:33 UTC 2026</i><br>
23-
<b>Messages:</b> 1<p>
22+
<b>Ending:</b> <i>Wed Feb 18 16:53:30 UTC 2026</i><br>
23+
<b>Messages:</b> 2<p>
2424
<ul>
2525

2626
<LI><A HREF="009977.html">[squid-dev] Architectural inquiry: Design rationale behind serialized request handling for identical URLs
2727
</A><A NAME="9977">&nbsp;</A>
2828
<I>&#1500;&#1497;&#1488;&#1493;&#1512; &#1489;&#1512;&#1488;&#1493;&#1503;
29+
</I>
30+
31+
<LI><A HREF="009978.html">[squid-dev] Architectural inquiry: Design rationale behind serialized request handling for identical URLs
32+
</A><A NAME="9978">&nbsp;</A>
33+
<I>Alex Rousskov
2934
</I>
3035

3136
</ul>
3237
<p>
3338
<a name="end"><b>Last message date:</b></a>
34-
<i>Wed Feb 18 10:59:33 UTC 2026</i><br>
35-
<b>Archived on:</b> <i>Wed Feb 18 11:17:58 UTC 2026</i>
39+
<i>Wed Feb 18 16:53:30 UTC 2026</i><br>
40+
<b>Archived on:</b> <i>Wed Feb 18 16:53:32 UTC 2026</i>
3641
<p>
3742
<ul>
3843
<li> <b>Messages sorted by:</b>

squid-dev/2026-February/subject.html

Lines changed: 9 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -19,20 +19,25 @@ <h1>February 2026 Archives by subject</h1>
1919
</a></b></li>
2020
</ul>
2121
<p><b>Starting:</b> <i>Wed Feb 18 10:59:33 UTC 2026</i><br>
22-
<b>Ending:</b> <i>Wed Feb 18 10:59:33 UTC 2026</i><br>
23-
<b>Messages:</b> 1<p>
22+
<b>Ending:</b> <i>Wed Feb 18 16:53:30 UTC 2026</i><br>
23+
<b>Messages:</b> 2<p>
2424
<ul>
2525

2626
<LI><A HREF="009977.html">[squid-dev] Architectural inquiry: Design rationale behind serialized request handling for identical URLs
2727
</A><A NAME="9977">&nbsp;</A>
2828
<I>&#1500;&#1497;&#1488;&#1493;&#1512; &#1489;&#1512;&#1488;&#1493;&#1503;
29+
</I>
30+
31+
<LI><A HREF="009978.html">[squid-dev] Architectural inquiry: Design rationale behind serialized request handling for identical URLs
32+
</A><A NAME="9978">&nbsp;</A>
33+
<I>Alex Rousskov
2934
</I>
3035

3136
</ul>
3237
<p>
3338
<a name="end"><b>Last message date:</b></a>
34-
<i>Wed Feb 18 10:59:33 UTC 2026</i><br>
35-
<b>Archived on:</b> <i>Wed Feb 18 11:17:58 UTC 2026</i>
39+
<i>Wed Feb 18 16:53:30 UTC 2026</i><br>
40+
<b>Archived on:</b> <i>Wed Feb 18 16:53:32 UTC 2026</i>
3641
<p>
3742
<ul>
3843
<li> <b>Messages sorted by:</b>

squid-dev/2026-February/thread.html

Lines changed: 12 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -19,8 +19,8 @@ <h1>February 2026 Archives by thread</h1>
1919
</a></b></li>
2020
</ul>
2121
<p><b>Starting:</b> <i>Wed Feb 18 10:59:33 UTC 2026</i><br>
22-
<b>Ending:</b> <i>Wed Feb 18 10:59:33 UTC 2026</i><br>
23-
<b>Messages:</b> 1<p>
22+
<b>Ending:</b> <i>Wed Feb 18 16:53:30 UTC 2026</i><br>
23+
<b>Messages:</b> 2<p>
2424
<ul>
2525

2626
<!--0 01771412373.9977- -->
@@ -29,11 +29,19 @@ <h1>February 2026 Archives by thread</h1>
2929
<I>&#1500;&#1497;&#1488;&#1493;&#1512; &#1489;&#1512;&#1488;&#1493;&#1503;
3030
</I>
3131

32+
<UL>
33+
<!--1 01771412373.9977-01771433610.9978- -->
34+
<LI><A HREF="009978.html">[squid-dev] Architectural inquiry: Design rationale behind serialized request handling for identical URLs
35+
</A><A NAME="9978">&nbsp;</A>
36+
<I>Alex Rousskov
37+
</I>
38+
39+
</UL>
3240
</ul>
3341
<p>
3442
<a name="end"><b>Last message date:</b></a>
35-
<i>Wed Feb 18 10:59:33 UTC 2026</i><br>
36-
<b>Archived on:</b> <i>Wed Feb 18 11:17:58 UTC 2026</i>
43+
<i>Wed Feb 18 16:53:30 UTC 2026</i><br>
44+
<b>Archived on:</b> <i>Wed Feb 18 16:53:32 UTC 2026</i>
3745
<p>
3846
<ul>
3947
<li> <b>Messages sorted by:</b>

squid-dev/index.html

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -25,7 +25,7 @@ <h1>The squid-dev Archives </h1>
2525
<A href="2026-February/author.html">[ Author ]</a>
2626
<A href="2026-February/date.html">[ Date ]</a>
2727
</td>
28-
<td><A href="2026-February.txt">[ Text 1 KB ]</a></td>
28+
<td><A href="2026-February.txt">[ Text 3 KB ]</a></td>
2929
</tr>
3030

3131

0 commit comments

Comments
 (0)