You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
> Thursday, April 16, 2026, 4:15:12 PM, you wrote:
1134
+
>> On 2026-04-16 07:41, Anthony Pankov wrote:
1135
+
>
1136
+
>>>> Alex: AFAICT, according to SslPeekAndSplice, after step1, Squid interprets "bump" as
1137
+
>>>> * "talk to the server and then respond to the client" rather than
1138
+
>>>> * "respond to the client and then talk to the server".
1139
+
>
1140
+
>
1141
+
>>> If a bump after step1 defined as "talk to the server and then respond
1142
+
>>> to the client" consequently Squid should not allow any "client-first"
1143
+
>>> modes.
1144
+
>
1145
+
>> Today, Squid probably does not support "respond to the client and then talk to the server" behavior after step1. Assuming that is true:
1146
+
>
1147
+
>> * That current code state does not imply that Squid "should not" support such behavior in the future.
1148
+
>
1149
+
>> * It implies that if Squid gains such support in the future, then that support is likely to require changes in how Squid configuration is interpreted, probably either by adding new actions (to preserve behavior of existing deployments) or allowing the existing "client-first" action beyond step1 (with a risk of breaking a few existing deployments that still use that currently deprecated action).
1150
+
1151
+
> Why I was asking was to know is there any roadmap for introducing new
1152
+
> actions or modifying configuration interpretation to do my changes
1153
+
> accordingly.
1154
+
1155
+
There is not. My earlier suggestions is the best I can offer as far as
1156
+
"roadmap" for new ssl_bump actions (or reinterpreting the existing but
1157
+
deprecated client-first action) is concerned (in this email thread
1158
+
context), but those suggestions are not official and (obviously) not
1159
+
comprehensive/polished/tested/etc.
1160
+
1161
+
If eventual official acceptance of your changes is critical, then it may
1162
+
be best to start with a proposal that details what you want to change.
1163
+
So far, I assumed that you mostly care about "working code" for your
1164
+
specific use case, allowing you to avoid the high burden of creating and
1165
+
passing official proposal review in this messy and poorly understood
TITLE="[squid-dev] forward bumped traffic to parent in plain form">rousskov at measurement-factory.com
23
+
</A><BR>
24
+
<I>Thu Apr 16 20:05:40 UTC 2026</I>
25
+
<P><UL>
26
+
<LI>Previous message (by thread): <AHREF="010014.html">[squid-dev] forward bumped traffic to parent in plain form
27
+
</A></li>
28
+
<LI>Next message (by thread): <AHREF="010010.html">[squid-dev] form PROXY header for cache_peer requests
29
+
</A></li>
30
+
<LI><B>Messages sorted by:</B>
31
+
<ahref="date.html#10016">[ date ]</a>
32
+
<ahref="thread.html#10016">[ thread ]</a>
33
+
<ahref="subject.html#10016">[ subject ]</a>
34
+
<ahref="author.html#10016">[ author ]</a>
35
+
</LI>
36
+
</UL>
37
+
<HR>
38
+
<!--beginarticle-->
39
+
<PRE>On 2026-04-16 10:36, Anthony Pankov wrote:
40
+
><i> Thursday, April 16, 2026, 4:15:12 PM, you wrote:
41
+
</I>>><i> On 2026-04-16 07:41, Anthony Pankov wrote:
42
+
</I>><i>
43
+
</I>>>>><i> Alex: AFAICT, according to SslPeekAndSplice, after step1, Squid interprets "bump" as
44
+
</I>>>>><i> * "talk to the server and then respond to the client" rather than
45
+
</I>>>>><i> * "respond to the client and then talk to the server".
46
+
</I>><i>
47
+
</I>><i>
48
+
</I>>>><i> If a bump after step1 defined as "talk to the server and then respond
49
+
</I>>>><i> to the client" consequently Squid should not allow any "client-first"
50
+
</I>>>><i> modes.
51
+
</I>><i>
52
+
</I>>><i> Today, Squid probably does not support "respond to the client and then talk to the server" behavior after step1. Assuming that is true:
53
+
</I>><i>
54
+
</I>>><i> * That current code state does not imply that Squid "should not" support such behavior in the future.
55
+
</I>><i>
56
+
</I>>><i> * It implies that if Squid gains such support in the future, then that support is likely to require changes in how Squid configuration is interpreted, probably either by adding new actions (to preserve behavior of existing deployments) or allowing the existing "client-first" action beyond step1 (with a risk of breaking a few existing deployments that still use that currently deprecated action).
57
+
</I>
58
+
><i> Why I was asking was to know is there any roadmap for introducing new
59
+
</I>><i> actions or modifying configuration interpretation to do my changes
60
+
</I>><i> accordingly.
61
+
</I>
62
+
There is not. My earlier suggestions is the best I can offer as far as
63
+
"roadmap" for new ssl_bump actions (or reinterpreting the existing but
64
+
deprecated client-first action) is concerned (in this email thread
65
+
context), but those suggestions are not official and (obviously) not
66
+
comprehensive/polished/tested/etc.
67
+
68
+
If eventual official acceptance of your changes is critical, then it may
69
+
be best to start with a proposal that details what you want to change.
70
+
So far, I assumed that you mostly care about "working code" for your
71
+
specific use case, allowing you to avoid the high burden of creating and
72
+
passing official proposal review in this messy and poorly understood
73
+
SslBump context.
74
+
75
+
Alex.
76
+
77
+
</PRE>
78
+
79
+
<!--endarticle-->
80
+
<HR>
81
+
<P><UL>
82
+
<!--threads-->
83
+
<LI>Previous message (by thread): <AHREF="010014.html">[squid-dev] forward bumped traffic to parent in plain form
84
+
</A></li>
85
+
<LI>Next message (by thread): <AHREF="010010.html">[squid-dev] form PROXY header for cache_peer requests
86
+
</A></li>
87
+
<LI><B>Messages sorted by:</B>
88
+
<ahref="date.html#10016">[ date ]</a>
89
+
<ahref="thread.html#10016">[ thread ]</a>
90
+
<ahref="subject.html#10016">[ subject ]</a>
91
+
<ahref="author.html#10016">[ author ]</a>
92
+
</LI>
93
+
</UL>
94
+
95
+
<hr>
96
+
<ahref="https://lists.squid-cache.org/listinfo/squid-dev">More information about the squid-dev
0 commit comments