On 2024-07-15 17:19, Amos Jeffries wrote:
On 12/07/24 10:10, Alex Rousskov wrote:
On 2024-07-11 17:03, Amos Jeffries wrote:
On 11/07/24 00:49, Alex Rousskov wrote:
On 2024-07-09 18:25, Fiehe, Christoph wrote:
I hope that somebody has an idea, what I am doing wrong.
AFAICT from the debuggin
On 12/07/24 10:10, Alex Rousskov wrote:
On 2024-07-11 17:03, Amos Jeffries wrote:
On 11/07/24 00:49, Alex Rousskov wrote:
On 2024-07-09 18:25, Fiehe, Christoph wrote:
I hope that somebody has an idea, what I am doing wrong.
AFAICT from the debugging log, it is your parent proxy that returns
sendet: Sonntag, 14. Juli 2024 18:59
>An: squid-users@lists.squid-cache.org
>Betreff: Re: [squid-users] Rewriting HTTP to HTTPS for generic package proxy
>
>Hi Alex,
>
>sorry, I have not seen your message, yet. Thank you very much for your helping
>support.
>
>(A) I will
gards,
Christoph
>-Ursprüngliche Nachricht-
>Von: squid-users Im Auftrag von
>Alex Rousskov
>Gesendet: Donnerstag, 11. Juli 2024 20:27
>An: squid-users@lists.squid-cache.org
>Betreff: Re: [squid-users] Rewriting HTTP to HTTPS for generic package proxy
>
>On 2024-07-11
et: Freitag, 12. Juli 2024 00:11
>An: squid-users@lists.squid-cache.org
>Betreff: Re: [squid-users] Rewriting HTTP to HTTPS for generic package proxy
>
>On 2024-07-11 17:03, Amos Jeffries wrote:
>> On 11/07/24 00:49, Alex Rousskov wrote:
>>> On 2024-07-09 18:25, Fiehe, Ch
On 2024-07-11 17:03, Amos Jeffries wrote:
On 11/07/24 00:49, Alex Rousskov wrote:
On 2024-07-09 18:25, Fiehe, Christoph wrote:
I hope that somebody has an idea, what I am doing wrong.
AFAICT from the debugging log, it is your parent proxy that returns an
ERR_SECURE_CONNECT_FAIL error page i
On 11/07/24 00:49, Alex Rousskov wrote:
On 2024-07-09 18:25, Fiehe, Christoph wrote:
I hope that somebody has an idea, what I am doing wrong.
AFAICT from the debugging log, it is your parent proxy that returns an
ERR_SECURE_CONNECT_FAIL error page in response to a seemingly valid
"HEAD http
ag, 11. Juli 2024 18:15
An: squid-users@lists.squid-cache.org
Betreff: Re: [squid-users] Rewriting HTTP to HTTPS for generic package proxy
On 2024-07-10 16:57, Fiehe, Christoph wrote:
I am just trying to find something that helps to narrow down the
problem. What I want to achieve is, that a client
ecurity -Wno-error=deprecated-declarations'
'LDFLAGS=-Wl,-Bsymbolic-functions -flto=auto -ffat-lto-objects -flto=auto
-Wl,-z,relro -Wl,-z,now ' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
'CXXFLAGS=-g -O2
-ffile-prefix-map=/home/builder/ubuntu22/build/squid/squid-6.8=. -f
On 2024-07-10 16:57, Fiehe, Christoph wrote:
I am just trying to find something that helps to narrow down the
problem. What I want to achieve is, that a client can use HTTP in the
LAN, so that Squid can cache distribution packages without making use
of SSL intercepting when repos are only access
"Caching objects.
>-Ursprüngliche Nachricht-
>Von: squid-users Im Auftrag von
>Fiehe,
>Christoph
>Gesendet: Mittwoch, 10. Juli 2024 22:58
>An: squid-users@lists.squid-cache.org
>Betreff: Re: [squid-users] Rewriting HTTP to HTTPS for generic package proxy
>
>
No problem. I am just trying to find something that helps to narrow down the
problem. What I want to achieve is, that a client can use HTTP in the LAN, so
that Squid can cache distribution packages without making use of SSL
intercepting when repos are only accessible via HTTPS. In that case the
prüngliche Nachricht-
Von: Alex Rousskov
Gesendet: Mittwoch, 10. Juli 2024 18:56
An: squid-users@lists.squid-cache.org
Cc: Fiehe, Christoph
Betreff: Re: [squid-users] Rewriting HTTP to HTTPS for generic package proxy
On 2024-07-10 12:42, Fiehe, Christoph wrote:
In the next test case, I used a m
g
>Cc: Fiehe, Christoph
>Betreff: Re: [squid-users] Rewriting HTTP to HTTPS for generic package proxy
>
>On 2024-07-10 12:42, Fiehe, Christoph wrote:
>
>> In the next test case, I used a more modern upstream proxy server based von
>> Squid 6.8
>and enable
T FD 19 flags=1 timeout -1
2024/07/10 18:24:44.064 kid1| 5,3| comm.cc(850) _comm_close: start closing FD
19 by Connection.cc:108
2024/07/10 18:24:44.064 kid1| 5,3| comm.cc(586) commUnsetFdTimeout: Remove
timeout for FD 19
2024/07/10 18:24:44.064 kid1| 83,3| Session.cc(36) tls_read_method: started for
conn482189
local=X.X.X.X:36718 remote=108.138.7.18:443 HIER_DIRECT FD 19 flags=1 timeout -1
2024/07/10 18:24:44.064 kid1| 5,3| comm.cc(850) _comm_close: start closing FD
19 by Connection.cc:108
2024/07/10 18:24:44.064 kid1| 5,3| comm.cc(586) commUnsetFdTimeout: Remove
timeout for FD 19
2024/07/
On 2024-07-09 18:25, Fiehe, Christoph wrote:
I hope that somebody has an idea, what I am doing wrong.
AFAICT from the debugging log, it is your parent proxy that returns an
ERR_SECURE_CONNECT_FAIL error page in response to a seemingly valid
"HEAD https://..."; request. Can you ask their admi
On 10/07/24 22:57, Fiehe, Christoph wrote:
The idea behind was to find a way to cache packages from a repository that only
provides HTTPS-based connections. It would work, when the HTTPS connection
terminates at the Squid Proxy and not at the client, so that the proxy can
forward the message p
Mittwoch, 10. Juli 2024 11:42
>An: squid-users@lists.squid-cache.org
>Betreff: Re: [squid-users] Rewriting HTTP to HTTPS for generic package proxy
>
>On 10/07/24 10:25, Fiehe, Christoph wrote:
>> Hallo,
>>
>> I hope that somebody has an idea, what I am doing wrong. I try
On 10/07/24 10:25, Fiehe, Christoph wrote:
Hallo,
I hope that somebody has an idea, what I am doing wrong. I try to build a
generic package proxy with Squid and need the feature to rewrite (not redirect)
a HTTP request to a package repository transparently to a HTTPS-based package
source.
T
20 matches
Mail list logo
