tor 2016-08-04 klockan 23:12 +1200 skrev Amos Jeffries:
>
>
> I imagine that Nginx are seeing latency reduction due to no longer
> needing a central worker that receives the connection then spawns a
> whole new process to handle it. The behaviour sort of makes sense for
> a
> web server (which
tis 2016-08-09 klockan 11:47 -0600 skrev Alex Rousskov:
>
> Yep, that matches both my understanding and motivation to return ERR
> in
> the explicitly configured on-persistent-overload=err case.
I'd say make it configurable.
on-persistent-overload=abort/err/ok/unknown
to represent all three
tis 2016-07-12 klockan 18:34 +1200 skrev Amos Jeffries:
> I'm much more in favour of binary formats. The HTTP/2 HPACK design
> lends
> itself very easily to binary header values (ie sending integers as
> interger encoded value). Following PHK's lead on those.
json is very ambiguous with no
sön 2016-07-10 klockan 11:33 +0100 skrev Kinkie:
> Hi all,
> at the end of the month I will attend the HTTP meetup in Stockholm.
> Besides having a chance to see Henrik, I'd like to collect your
> feedback and opinions on the topic that are likely to be touched.
Oh, This have completely
mån 2015-03-16 klockan 04:03 +0200 skrev Eliezer Croitoru:
My main concern until now is that if squid would have the cached object
in a digest url form such as:
http://digest.squid.internal/MD5/xyz123;
Squid would in many cases try to verify against the origin server that
the cached
tis 2015-03-10 klockan 23:58 +1300 skrev Amos Jeffries:
There is approximately 8-18 months year between series releases now. A
very arbitrary choice whenever it seems reasonable to release a batch of
features. My undertanding of the proposal stated was that we keep that
current practice, but
sön 2015-03-08 klockan 07:49 +0100 skrev Kinkie:
Beta releases can be managed just like they are now:
MAJ.0.X would be beta
MAJ.Y (Y=1) would be stable
Correct.
Today we have release numbers that is made of major.minor (2.5, 3.0,
3,1.., 3.5), followed by patchlevel where beta releases are
fre 2014-07-25 klockan 19:05 +0300 skrev Eliezer Croitoru:
The response to alex question why would anybody want to drop
cteonnt-length: header:
Some places do not allow cookies or POST for external services and it's
sometimes can looks weird but I still understand why would it be
lör 2014-07-19 klockan 11:35 -0600 skrev Alex Rousskov:
The above email is talking about a nnCoection: close header which
appears to be a result of a bug in some 15-year old software.
Identifying that rare header would be overall harmful -- Squid would
spend more resources on detecting that
tor 2014-06-12 klockan 21:01 +1200 skrev Amos Jeffries:
When FTP transfer protocol is added is the time to determine if the fpt_
prefix is actually necesary or the *existing* protocol= parameter can be
used alone. FWIW the only strong reason http_ and https_ are currently
used is to determine
sön 2014-06-08 klockan 23:05 +1200 skrev Amos Jeffries:
When a change can it should avoid being a flag-day. But if breaking into
a set of smaller incremental changes is difficult or causes too much
annoyance from repeated painful merges or wastes audit time on other
patches, then it seems
It looks like Mozilla is finally adding support for TLS encrypted proxy
connections.
So if we still have the problem with CONNECT not properly handling TLS
then it might we a good idea to finally fix that.
Regards
Henrik
ons 2014-04-30 klockan 06:22 +1200 skrev Amos Jeffries:
HTTP defines no limit.
- squid defines MAX_URL of 8KB, along with a header line limit of 64KB
total, and a helper line limit of 32KB total.
Unless it has been fixed the UFS based stores also have an implicit
limit on cached entries
tis 2014-03-11 klockan 09:53 +0200 skrev Tsantilas Christos:
No objection, just to note that these algorithms are implemented in
openssl library too and squid already has dependencies to openSSL.
And in Squid-2 used OpenSSL MD5 if linked to OpenSSL, or some system MD5
implementation (i.e.
tor 2014-02-13 klockan 09:43 -0700 skrev Alex Rousskov:
I am not sure which approach is the best, but I am sure we need to
clearly define and document the new semantics to avoid repeating -N
problems which were caused primarily by folks (including myself)
interpreting what -N means
ons 2014-02-12 klockan 10:13 +1300 skrev Amos Jeffries:
Sigh.
Amos
Why sigh? systemd have worked well for me for years now.. except Squid..
For Squid the main impact is that we really should have a dont
daemonize yourself run mode which don't otherwise limit functionality.
The -N option we
ons 2014-02-12 klockan 10:47 +1300 skrev Amos Jeffries:
Exactly. More deep changes needed.
Well, systemd (and most other service monitors) do manage services that
background themselves as well, just not optimally. So it's more changes
desired, not strictly needed.
But seriously, it's a very
mån 2014-02-10 klockan 21:48 +1300 skrev Amos Jeffries:
FYI for anyone interested in the HTTP/1.1 compliance project or related
work. The HTTPbis drafts are now etched in stone.
You can find links to the HTTPbis work on 1.1 and 2.0 protocols here:
ons 2014-01-29 klockan 13:29 +1300 skrev Amos Jeffries:
hard-coded is being used a bit much here. I don't think any of us are
arguing for that.
Lets look at the BNF:
FOO.pid = chroot pid_filename
chroot = {squid.conf chroot} | /
pid_filename = {squid.conf pid_filename} |
tis 2014-01-28 klockan 11:25 -0700 skrev Alex Rousskov:
Why do we need a command line option to specify a service name? Can the
service name be configured via squid.conf? The squid.conf location is
already configurable via command line, of course.
If I remember correctly the service name is
tis 2014-01-28 klockan 12:15 -0700 skrev Alex Rousskov:
but squid.conf location is already configurable via the command line.
Why another option, that is now propagated to non-Windows builds,
without even defining what service is in non-Windows context (AFAIK).
If I am not mistaken the
sön 2014-01-26 klockan 13:59 +1300 skrev Amos Jeffries:
So how do we safely allow users to configure where the IPC sockets are
located on a per-worker basis while also allowing workers to communicate
over them to each other?
Please elaborate.
How do using a service name for these differ from
fre 2014-01-24 klockan 08:57 -0700 skrev Alex Rousskov:
Please note that since Windows admins want a service name even if they
do not run multiple single-build instances on the same box, setting that
service name should not suddenly make their life more difficult by
altering squid.conf
fre 2014-01-24 klockan 14:27 -0700 skrev Alex Rousskov:
using the same Squid build (bug 3608). That bug report contains a
suggestion to make the currently ./configure-set IPC paths explicitly
configurable in squid.conf, but using service name side-effects also
works. I am not sure which
tor 2014-01-23 klockan 09:53 +0200 skrev Eliezer Croitoru:
Since I do have a local server I want to have an up-to-date bzr replica.
I can just use checkout or whatever but I want it to be be updated etc.
I am no bzr expert so any help about the subject is more then welcome.
What I do is that
tis 2014-01-21 klockan 22:45 -0700 skrev Alex Rousskov:
All the TCP clients and servers you are willing to include (as future
TcpReceiver kids) in the current project scope have at least one thing
in common -- they all read and write protocol messages over [persistent]
TCP connections. Why do
tis 2014-01-21 klockan 14:37 -0700 skrev Alex Rousskov:
[FWIW, the term FTP Gateway was suggested by Henrik during initial RFC
review. Henrik thought that using HTTP semantics internally means we are
a gateway. I changed the project name in order to avoid having an
argument. Technically, it is
mån 2014-01-20 klockan 11:45 -0700 skrev Alex Rousskov:
FTP gateway[1] code[2] work well, and we are polishing it for the
official submission. The biggest change we need to make is to rearrange
where the new code lives in Squid src directory.
For the record I have no opinion on either of
tis 2013-08-13 klockan 16:01 -0600 skrev Alex Rousskov:
the urltag approach used in squid-2 could be used here as general
mechanism. It allows http_port or external_acl to add a piece to the
object key.
This allows splitting cache based on
- port received on
- username
-
ons 2013-08-07 klockan 16:51 +1200 skrev Amos Jeffries:
My previous thoughts around this have all revolved around the idea of
adding the clients IP address to the cache key when private proxy mode
is enabled. This has a major issue though in that it does not solve
anything for users with
Found this expired in the list moderation queue.
Sorry, can't really help much with mingw build environment issues but
maybe someone on the list knows? or at least what mingw installation
documentation to read?
ons 2013-05-15 klockan 14:25 +0100 skrev Srini:
Hi,
I am trying to compile Squid
tor 2013-07-25 klockan 14:20 -0600 skrev Alex Rousskov:
The variant of an URL is identified by it's ETag value.
Are ETags required by HTTP in a Vary context? Or is it just what you see
some origin servers implementing?
To identify the variant yes. Without ETag the variant have no identiy.
tor 2013-07-25 klockan 23:37 +0300 skrev Eliezer Croitoru:
The main problem with ETAG from what I have seen and I need to read more
about ETAG, is..
couple mirrors ETAG should be the same for all servers objects in the
level of HASH like.. which is not.. an example:
ETag uniqueness is only
fre 2013-07-26 klockan 14:44 +0300 skrev Eliezer Croitoru:
So etag is fine but per server or per url.
ETag is per URL.
metalink\hashes are more global.
Yes.
since the list of mirrors is big and there is a list of them it would be
very simple to use StoreID helper to identify them faster
ons 2013-07-24 klockan 18:46 -0600 skrev Alex Rousskov:
The full logics (still missing from squid-3) involves an n-m map of
requests to response variants.
I thought Squid already tries to support that. Or are you talking about
responses with varying Vary header values (discussed further
tor 2013-07-25 klockan 17:23 +1200 skrev Amos Jeffries:
We think alike. See my other reply. Although the lookup per-match is not
required. HTTP only requires that we identify a whole set of options and
pull the most appropriate - with some requirements around defining
appropriate.
newest
tor 2013-07-25 klockan 18:53 +1200 skrev Amos Jeffries:
Which problem specifically? that churn exists? that it can grow big +
churn? races between clients? or that letting it out to disk can cause
churn to be slooow?
In the design used by Squid-2 there is quite a bit of churn in the
x-vary
tor 2013-07-25 klockan 22:06 +1200 skrev Amos Jeffries:
I don't see why those are necessary. At the x-vary level all that is
necessary is the response details to be searched for in the request
headers. ie if x-vary says variant has Content-Encoding:gzip then
search for Accept-Encoding:gzip
ons 2013-07-24 klockan 10:01 -0600 skrev Alex Rousskov:
That is what Squid does today, bugs notwithstanding. If the found store
entry is the special Vary entry, then Squid does another lookup, with
the appropriate header values added to the store key hash.
Yes, but is only part of what is
ons 2013-07-17 klockan 23:34 +1200 skrev Amos Jeffries:
Also, I think if the variant needs to be invalidated Squid currently
coded to drop all variants and/or the main x-vary-* stub object during
revalidation. The HTTP/1.1 specs need to be checked to see if that is
right or if only the one
tor 2013-06-13 klockan 23:59 +1200 skrev Amos Jeffries:
As a temporary measure, how about adding a directive log_stats
allow/deny acl acl acl ... and using it only for the statistcs
gathering functions as done by log_access allow?
That's fine for me. But should be named something more
tor 2013-06-13 klockan 08:16 -0600 skrev Alex Rousskov:
I suggest stats_collection because it works better with allow/deny
keywords that will follow:
stats_collection deny internal
+1
Regards
Henrik
ons 2013-06-12 klockan 14:25 +1200 skrev Amos Jeffries:
Please also note in the descriptive message that this alters the
documented behaviour of Requests denied for logging will also not be
accounted for in performance counters., and now makes all traffic get
performane counters
tor 2013-06-13 klockan 02:18 +0300 skrev Eliezer Croitoru:
I have seen the wiki:
http://wiki.squid-cache.org/Features/Socks
Nothing implemented. And have not been given any priority as it's not
HTTP related.
and was wondering about it very much!
I have a situation that I have access to SSL
tis 2013-06-04 klockan 11:48 +0300 skrev Eliezer Croitoru:
I was wondering about the major bugs that was found in 3.1 that RH and
therefor CentOS doesn't have in their RPMS.
Double negation there?
Have you tried tiling a bug report in redhat bugzilla? It's the best
contact method available
tis 2013-02-12 klockan 14:41 -0700 skrev Alex Rousskov:
Hello,
Could somebody with better authentication and helper knowledge clarify
whether the token field is indeed required for Nagotiate ERR and NA
responses? If not, can we just remove the above quoted fatalf() blob and
make the
ons 2013-02-13 klockan 14:41 +1300 skrev Amos Jeffries:
Yes you can remove these fatal() if you want, but it needs to result in
authentication failure
NA is authentication failure. Must not result in anything else.
Regards
Henrik
ons 2013-01-30 klockan 12:21 + skrev Rainer Weikusat:
Thank you. The reason I'm asking is mainly because 0-delay events are,
according to the comment in schedule, supposed to be executed in FIFO
order. Is this generally true for events, ie is the actual ordering
criterion always a pair
mån 2013-01-28 klockan 22:29 + skrev Rainer Weikusat:
Since Mr Rousskov was so kind to publically question my honesty and/or
mental sanity when I claimed that replacing the O(n) event scheduler
with a more scalable implementation would be easy (and in fact, so
easy that even using the STL
ons 2013-01-23 klockan 18:41 +1300 skrev Amos Jeffries:
With HTTP/1.1 functionality Variants are much more common and the ICP
failure rate is growing quite high.
Yes..
I propose altering the default behaviour of peering to using HTCP
queries by default.
If HTCP is fixed to handle
fre 2013-01-11 klockan 18:53 +1300 skrev Amos Jeffries:
Can anyone present any actually useful reason to keep it despite the
problems it presents?
referse proxies need to be able to cache error responses even if there
is no cache-control. But it does not need to be a specific directive.
tor 2012-12-27 klockan 13:38 +1300 skrev Amos Jeffries:
IIRC it is still off because it is not wanted by many installations and
adds a large footprint to the binary. The more useful
surrogate-capabilities sub-component is auto-enabled on reverse-proxy
traffic regardless of ESI.
Plus still
tor 2012-12-13 klockan 00:45 -0800 skrev Tianyin Xu:
Accoding to the code, when setting tcp_recv_bufsize, Squid also set
the same amount as tcp_send_bufsize? And the send log printing message
(line# 1794) seems problematic because the failure is caused by
setting tcp_send_bufsize (the flag is
tor 2012-12-06 klockan 21:54 +0200 skrev Eliezer Croitoru:
On cache log I am getting these:
2012/12/06 21:34:29.780 kid3| commBind: Cannot bind socket FD 10 to
[::]: (13) Permission denied
Odd.. the debug output indicates this is a request for assigning an
ipv6:port.
What do strace say?
mån 2012-12-03 klockan 22:25 -0700 skrev Alex Rousskov:
I disagree with this logic. Yes, sawActivity approach supports long
chains, but they are not the loop's fault! If some chain is too long,
the bug is in that chain's code and should be fixed there. If it cannot
be fixed there, then the
mån 2012-12-03 klockan 23:12 -0700 skrev Alex Rousskov:
BTW, once zero-delay events are removed from the code, the event queue
will no longer need to be a part of the wasActivity loop and the loop
will disappear.
Note: Legacy zero-delay addEvent events are meant to be called once per
comm
tis 2012-12-04 klockan 08:39 -0700 skrev Alex Rousskov:
heavy events in the context of addEvent events are really this is very
heavy, and there is only allowed to be one and only one heavy event per
comm invocation. If there is multiple heavy jobs competing for time they
are meant to get
tis 2012-12-04 klockan 08:39 -0700 skrev Alex Rousskov:
There are several ways to interpret the designer intent when looking at
undocumented code. I cannot say whether all of the currently remaining
zero-delay events use your interpretation, but I am certain that I have
added zero-delay
sön 2012-12-02 klockan 22:27 -0700 skrev Alex Rousskov:
My understanding is that the bug is in Squid store rebuilding(?) code
that assumes that Squid will have time to do some I/O before the next
timed event is fired, but actually there is a lot of non-I/O work to do,
In such case the bug is
mån 2012-12-03 klockan 09:07 -0700 skrev Alex Rousskov:
Yes. IIRC, it has been broken before my AsyncCall changes to the main
loop.
The sawActivity code is from the AsyncCall merge in rev 8812.
This will poll non-comm event loops until they are completely idle
having nothing to do.
mån 2012-12-03 klockan 15:53 -0700 skrev Alex Rousskov:
True (although the current small maximum select(2) delay is a result of
bugs elsewhere in the code and should not really be there). If we can do
the right thing here easily, we should (instead of adding more future
problems). And I think
mån 2012-12-03 klockan 15:53 -0700 skrev Alex Rousskov:
We just need to make sure that heavy events (certain timed events and
signals) interrupt the sawActivity loop. This will fix the issue you are
facing without introducing new problems.
Another question on this.. how to fit the concept of
mån 2012-12-03 klockan 09:07 -0700 skrev Alex Rousskov:
Could you please fix this properly by adding
AsyncEngine::timeTillNextEvent() or similar API and removing loop_delay
manipulation from checkEvents() as discussed above?
The attached patch adds AsyncEngine::timeTillNextEvent() API. It
lör 2012-12-01 klockan 18:02 -0700 skrev Alex Rousskov:
a) If we are talking about unretriable requests, the client already
violated HTTP by sending such a request over the persistent client
connection. Some of these clients may fail to handle resets properly.
End-user-agents have much more
fre 2012-11-30 klockan 15:38 -0700 skrev Alex Rousskov:
On 11/30/2012 02:25 PM, Henrik Nordström wrote:
We should look into why it is at all needed. From what I can understand
it should not be needed.
Agreed. Please do that if you can.
Found it. The event loop gets saturated with timed
fre 2012-11-30 klockan 23:07 -0700 skrev Alex Rousskov:
I am not sure what you are asking about, but I can try to rephrase: This
bug is difficult to fix because some pinned connections should be reused
and some should not be. Pinned connections that can be re-pinned but
have not had any HTTP
lör 2012-12-01 klockan 11:42 -0700 skrev Alex Rousskov:
come. Why can't TPROXY reopen a server-side connection?
Because it tries to use the original source ip:port, but it's in
TIME_WAIT from the previous connection and can't be reused.
Regards
Henrik
fre 2012-11-30 klockan 10:47 -0700 skrev Alex Rousskov:
IIRC, Rock store diskers should process queries while rebuilding so db
open should not fail due to rebuild itself. I bet this is actually
related to the problem discussed below.
I think so too.
- kid registration failures at startup
fre 2012-11-30 klockan 15:30 -0700 skrev Alex Rousskov:
Squid is sending POST requests on reused pinned connections, and
some of those requests fail due to a pconn race, with no possibility for
a retry.
Yes... and we have to for NTLM, TPROXY and friends or they get in a bit
of trouble
While trying to set up an advanced Squid-3.2.3 with 4 workers, a number
of rock stores for different objects and per-worker aufs caches for
larger files I ran into multiple issues.
- Quite frequent NULL pointer assertions failures in peer selection if
the client aborts before peer selection have
tor 2012-11-29 klockan 15:08 +1300 skrev Amos Jeffries:
Does anybody know the rationale for having xmemset at all?
I don't see muhc of a meaningful rationale.
memory debugging tools already handle it without any wrapper.
Regards
Henrik
tis 2012-11-27 klockan 04:44 +0200 skrev Eliezer Croitoru:
I tried to build squid 3.2.3 on fedora 17 x64 and got an error.
compiling options
-g -O2 -c -o certificate_db.o certificate_db.cc
certificate_db.cc: In member function גvoid Ssl::CertificateDb::load()ג:
certificate_db.cc:460:76:
ons 2012-11-21 klockan 21:06 +0200 skrev Eliezer Croitoru:
The problem is that it only being checked while a file is being fetched
from UFS(what I have checked) while from RAM it wont be checked.
There is no risk of object store displacement in RAM.
The result is that when store_url_rewrite
yadi hno: can you confirm that it is okay to simply swap the Counter32
SNMP OID type to Counter64 without changing OID numbers?
Generally it's not OK to change existing entries, quite many pollers
configure the data type. But it is a balance. Both changing data types
and changing the MIB with a
tis 2012-10-16 klockan 05:39 +0200 skrev Eliezer Croitoru:
I did that already and I get error while updating:
##start
$ bzr update
Doing on-the-fly conversion from RepositoryFormat2a() to
RepositoryFormatKnitPack6().
This may take some time. Upgrade the repositories to the same format
tor 2012-10-11 klockan 13:30 +1300 skrev Amos Jeffries:
Did you mean we should have no cost being part of their program? or
that there is an admin control panel (contact person?) you have
available to do more than I could?
There is no charge to be part of their Open Source program, and
tor 2012-10-11 klockan 23:23 +0200 skrev Kinkie:
Please once you're done, please share the recipe so I can try to hook
it into Jenkins for CI.
It's quite simple. Basically a normal build but wrapping the make call
in a cov-build tool by them, and then uploading the result written by
their
Squid is a member of the Coiverity Open Source programme, but we have
not been actively using it.
tis 2012-10-09 klockan 00:27 +0400 skrev Dmitry Kurochkin:
Hello.
We are evaluating Coverity tool for static analyzing of Squid code (see
bug 3635 for details [1]). Initial results with
lör 2012-10-06 klockan 17:24 +0200 skrev Eliezer Croitoru:
Code implementation is quite simple but since I was working with the old
bzr revision 12317 ant now its about 30 revisions up I dont have a clue
on what to do.
are you stuck on repository format upgrade, or on incompatible changes
fre 2012-09-14 klockan 08:23 -0600 skrev Alex Rousskov:
Interesting. I did not expect much support for this, but two out of
three responses so far suggest this approach, essentially. When the dust
settles, perhaps we should post to squid-users as well to get more feedback?
clarity have higer
tor 2012-09-13 klockan 12:05 +1200 skrev Amos Jeffries:
Just had a thought. I wonder if this is related to the releases which
people suddenly started having cache MISS for a period with no visible
reason.
That could be the releases where we added/removed methods from the
registered set.
tor 2012-09-13 klockan 12:07 +0300 skrev Eliezer Croitoru:
but in the logs is see a lot:
2012/09/13 11:48:51.798 kid1| StoreEntry::checkCachable: NO: not cachable
Is it a 200 OK response. Suspect it's a 304?
Regards
Henrik
ons 2012-09-12 klockan 10:18 +0300 skrev Eliezer Croitoru:
For the no cachable situation something should be done to lower
performance issues that could come from using store_url, some kind of
flag validation before sending it to the helper?
That only helps in the case where we know from
tor 2012-09-13 klockan 11:20 +1200 skrev Amos Jeffries:
I think long-term we want to have ICAP/eCAP generating ETag+Digest
headers for requests and responses and store using those headers as the
index key.
How do you generate an ETag from a request?
ETag is a response header, set by the
ons 2012-09-12 klockan 10:26 +0300 skrev Eliezer Croitoru:
if it was a string what will be the string structure?
It's not a string.
The first hashed octet is the Squid internal method representation in
binary integer form. Followed by the requested URL.
See storeKeyPublic() function for
As per prior discussions the bzr repository have now been upgraded to 2a
format.
New master repository layout is a flat layout with branches
trunk
3.2
3.1
3.0
more branches will be migrated over on a need basis.
There is also branches/... symlinks in place so old branch URLs
tis 2012-09-11 klockan 15:52 -0600 skrev Alex Rousskov:
Hm... I wonder if we are making a design mistake here by following
Squid2 steps: one helper to rewrite request URL, one helper to rewrite
store URL, then one helper to rewrite some special HTTP header, etc.
Would it be better to extend
ons 2012-09-12 klockan 11:05 +1200 skrev Amos Jeffries:
However, we want also to back-port this feature into 3.2 (3.1?) and
maintain upgrade compatibility with 2.7 implementation, at least to
start with.
Do we really want to backport new features?
Regards
Henrik
mån 2012-09-10 klockan 15:11 +0100 skrev Konstantin Korsunov:
All working good, but some times 3 times per day I have next error:
Failure Ratio at 1.02
Going into hit-only-mode for 5 minutes...
That means that an unexpected amount of the proxied requests have
failed, and to avoid further
sön 2012-09-09 klockan 19:15 +0200 skrev Kinkie:
It seems that the schedule was missed.
Yes. Been ill since friday. Combination of sleep deprivation and a cold
taking it's poll.
When is the next chance?
Haven't seen any indications of any remaining reasons to not being able
to switch.
sön 2012-09-09 klockan 21:34 +1200 skrev Amos Jeffries:
Henrik and I seem to disagree on this being a good idea being plugged
into BodyPipe. But as I see it BodyPipe is where Upgrade, WebSockets and
SSL-Bump should be happening in a node which internally receives the
tunnel connection and
fre 2012-09-07 klockan 21:54 -0600 skrev Alex Rousskov:
However, when the proxy receives a CONNECT request, it diverts the
request to tunnel.cc. Tunnel.cc is aware of peer selection logic but
lacks the code that establishes an SSL connection to SSL peers.
Yes, long time bug that no one has
ons 2012-09-05 klockan 09:03 +0200 skrev Kinkie:
I'm glad that a consensus is forming.
The next question would then be who will perform the upgrade, and when
- assuming noone speaks up against it.
This friday?
Regards
Henrik
tis 2012-09-04 klockan 11:00 -0600 skrev Alex Rousskov:
It would be nice to have specific instructions on how to update a local
branch to support 2a. I see bzr upgrade command but it is not clear
whether that is sufficient, especially with all the talk about two
repositories (old and 2a).
tis 2012-09-04 klockan 12:22 -0600 skrev Alex Rousskov:
A FTP client-side might be accepted, allowing Squid to act as an
ftp-ftp gateway using HTTP semantics internally, even accepting
ftp-http gatewaying if you want. But not sure it makes sense to add
native FTP proxy support.
Can you
tis 2012-09-04 klockan 16:29 -0600 skrev Alex Rousskov:
Why would the second approach be required by some? In other words,
what kind of FTP functionality the first approach cannot support? I do
not favor the second approach, but I would like to know what we are
losing by using the first
tis 2012-09-04 klockan 10:56 +1200 skrev Amos Jeffries:
FWIW: I'm in favour of the upgrade, it is a large part of the build
timeout issues on rio Debian sid build slave, it causes timeouts while
converting the repo changes and/or downloading large portions of repo
changeset data before for
fre 2012-08-31 klockan 10:58 +0300 skrev Tsantilas Christos:
1) To decide if it can reuse a healthy persistent connection. Inside
FwdState::connectStart, we are getting a persistant connection and even
if it is healthy, if we want to send eg a PUT request we are closing the
persistent
fre 2012-08-31 klockan 21:44 +0300 skrev Tsantilas Christos:
So looks that a good solution should be (similar to) the solution
proposed by Henrik...
100 Continue aviods the race entirely on requests with bodies, leaving
only bodyless requests in the we may not retry this on failure but we
need
ons 2012-08-29 klockan 12:42 -0600 skrev Alex Rousskov:
Hello,
I saw bogus ERR_ZERO_SIZE_OBJECT responses while testing Squid v3.1,
but the same problem ought to be present in v3.2 as well.
A compliant proxy may retry PUTs, but Squid lacks the [rather
complicated] code required to
1 - 100 of 597 matches
Mail list logo
