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
> co
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 t
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 determ
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 so
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. Sol
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 differe
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 s
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
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:
> http://trac.tools.ietf.org/wg/httpbis/t
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_filena
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 se
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
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 fr
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 app
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 loc
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 t
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
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
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
> > - usern
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 wit
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 Squ
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 faste
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 onl
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 ident
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-Encodin
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-var
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".
ne
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
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
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
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 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 S
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 counte
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 f
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
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 foll
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 S
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
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 varia
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.
Merg
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 st
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
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?
>
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 ev
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 mean
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 l
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 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 a
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 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 th
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.
>
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 i
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 e
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
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 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 HTT
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 f
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 start
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
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 c
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: e
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_rewri
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 new OI
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 fo
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 too
tor 2012-10-11 klockan 22:39 +0200 skrev Kinkie:
>
> There is no charge to be part of their Open Source program,
> and they did
> respond in past when dealing with them.
>
> I can try contacting them to reviewe the Squid scan if wanted.
>
> Yes, pl
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 t
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 ana
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 hige
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: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 fro
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
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 se
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 continu
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 detai
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
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 exten
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 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
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.
Wed
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 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 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.
>
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 11:41 +1200 skrev Amos Jeffries:
> > There is also an alternative layout tree at /bzr/squid3-new-2a/ which
> > flattens the tree to
> >
> > ../
> > trunk
> > 3.0
> > 3.1
> > 3.2
> >
> > getting rid of the CVS references and other legacy.
>
> Does this ob
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
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
ne
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 con
ons 2012-08-29 klockan 15:32 -0600 skrev Alex Rousskov:
> Today, we have a choice:
>
> A. Fail some PUTs. Close fewer pconns (current code).
> B. Handle all PUTs. Open more connections (patched code).
>
> If this patch is accepted, performance bug 3398 will resurface. Henrik,
> do you think
ons 2012-08-29 klockan 22:20 +0200 skrev Henrik Nordström:
> 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.
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
sön 2012-08-26 klockan 19:28 +0100 skrev Markus Moeller:
> Why can't I use the function multiple times in a printf line ?
because it uses a static return buffer, you need to copy the resulting
string somewhere before making the next call.
Regards
Henrik
fre 2012-08-17 klockan 18:03 -0600 skrev Alex Rousskov:
> What do you think about adding native or pure FTP proxying support
> to Squid? That is, is it a good idea for Squid to start accepting pure
> FTP requests (not wrapped in HTTP).
Not sure. It shares very little in common with HTTP proxy
Those TODO are for future planed code changes, and unrelated to the
asser().
The object is empty here unless
a) There is memory reference error / corruption
b) Something attempts to stuff two replies into the same object.
Regards
HEnrik
fre 2012-08-17 klockan 13:55 -0700 skrev Linda W:
> Alex
1 - 100 of 642 matches
Mail list logo
