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
c: Fiehe, Christoph
Betreff: AW: [squid-users] Rewriting HTTP to HTTPS for generic package proxy
On 2024-07-10 15:31, Fiehe, Christoph wrote:
The problem is that the proxy just forwards the client GET request to the
upstream proxy
Why does sending a GET request to the upstream proxy represent a
"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
>
>
uli 2024 22:15
>An: squid-users@lists.squid-cache.org
>Cc: Fiehe, Christoph
>Betreff: AW: [squid-users] Rewriting HTTP to HTTPS for generic package proxy
>
>On 2024-07-10 15:31, Fiehe, Christoph wrote:
>> The problem is that the proxy just forwards the client GET request to 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
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. I was able to get Jesred working and defined the
21 matches
Mail list logo