On 06/01/2014 02:37 AM, Amos Jeffries wrote:
> Lets take a step aside and cover why the buf2 is a pointer instead of an
> separate SBuf.
I do not think those reasons are important enough in this context. It is
like suggesting "let's examine the benefits of using uninitialized
variables and creatin
On 06/02/2014 11:27 AM, Kinkie wrote:
>>> +//fixme: account for buf_.size()
>>> +bool neg = false;
>>> +const char *s = buf_.rawContent();
>>> +const char *end = buf_.rawContent() + buf_.length();
>>
>> Could you please explain what the above comment means? There is no
>> SBuf::size
On 06/01/2014 03:04 PM, Francesco Chemolli wrote:
>
> revno: 13429
> committer: Francesco Chemolli
> branch nick: trunk
> timestamp: Sun 2014-06-01 23:04:31 +0200
> message:
> Copy compat from compat/strtoll.c to Tokenizer.cc
> === mo
On 05/30/2014 03:56 AM, Kinkie wrote:
> Hi,
> here's the patch for merging the sbuf-tokenizer branch. Includes the
> fixes to Parser::Tokenizer::int64 method (via reimplementation of
> strtoll to account for SBufs sharing MemBlobs).
>
> Please review.
> +Parser::Tokenizer::token(SBuf &returned
On 05/20/2014 05:17 AM, Amos Jeffries wrote:
> On 20/05/2014 4:28 a.m., Alex Rousskov wrote:
>> New temporary SBuf allocations for message parts will be removed as you
>> polish the parsing code, right? Or are you proposing to commit those
>> performance regressions fi
On 05/19/2014 12:29 AM, Amos Jeffries wrote:
> Updated patch attached. PREVIEW since the file renaming has been
> omitted, as have incomplete Tokenizer related changes.
I have not reviewed most of the details, but the preview looks good to
me overall.
New temporary SBuf allocations for message p
On 05/11/2014 07:57 AM, Amos Jeffries wrote:
> ClientSocketContext represents a whole transaction. The request, where
> its up to in processing, the reply headers, and where the reply body is
> up to in delivery. It is "active" from end of parsing request headers to
> after delivering the last byt
On 05/13/2014 04:39 AM, Amos Jeffries wrote:
> On 13/05/2014 9:04 a.m., Alex Rousskov wrote:
>> Performance concerns: To determine whether the requested object is in
>> the cache, SMP Store requires semi-expensive lookups (one for each SMP
>> cache_dir and one for the shar
On 05/13/2014 02:45 AM, Steve Hill wrote:
> On 12.05.14 18:20, Alex Rousskov wrote:
>> The Token class in v3.4 uses an ugly union (instead of "struct") for the
>> data member. Thus, data.timespec should be identical to data.string. The
>> fact that changing .timespe
On 05/13/2014 04:03 AM, Amos Jeffries wrote:
> On 13/05/2014 10:46 a.m., Alex Rousskov wrote:
>> On 05/11/2014 11:16 AM, Amos Jeffries wrote:
>>> Unlike the char* API the buffer can be appended to before write(2) is
>>> completed and the appended bytes will be hand
On 05/09/2014 01:31 PM, Amos Jeffries wrote:
> +const SBuf &userInfo(void) const {return userInfo_;}
Please avoid "(void)" in new code and use "()" for consistency with most
C++ code.
> +if (checklist->request->url.userInfo().isEmpty()) {
> +debugs(28, 5, "URL has no user-info d
On 05/11/2014 11:16 AM, Amos Jeffries wrote:
> This patch adds a Comm::Write API for accepting SBuf output buffers.
> Unlike the char* API the buffer can be appended to before write(2) is
> completed and the appended bytes will be handled as part of the original
> write request.
That approach s
On 05/11/2014 05:29 AM, Amos Jeffries wrote:
> This patch seeks to reduce the constant MISS situation we have from
> false failures doing Host: header verify.
General comments:
FWIW, I have a general feeling we are going to regret the proposed
change, but I do not have enough specific reasons to
On 05/12/2014 10:47 AM, Steve Hill wrote:
> Squid 3.4.5 segfaults when formatting log lines for me. It looks like
> this is down to fmt->data.timespec being uninitialised, and affects the
> %tg format specifier.
>
> As far as I can tell, fmt->data.timespec is never set anywhere, and we
> should
On 05/08/2014 11:17 AM, Amos Jeffries wrote:
> This refactors the request pipeline management API to use std::queue
> instead of a custom linked-list with accessors spread over both
> ConnStateData and ClientSocketContext.
>
> To do this a new class Pipeline is created with methods wrapping
> std:
l (r13406).
Thank you,
Alex.
> ----
> From : Alex Rousskov
> To : squid-dev@squid-cache.org;
> Subject : Re: Segmentation fault in FwdState::serverClosed
>
>
> On 05/08/2014 11:49 AM, Amos Jeffries
On 05/08/2014 11:49 AM, Amos Jeffries wrote:
>>> Something is still calling serverConn->close() directly
In your particular trace, HttpStateData::continueAfterParsingHeader()
does that, but there are many other methods doing the same thing.
AFAICT, the idea is that the close handlers will clean u
On 05/08/2014 07:21 AM, Amos Jeffries wrote:
> This is a side effect of trunk rev.13388 (standby connections)
If this is something you can reproduce, please post/share an ALL,9
cache.log.
> Something is still calling serverConn->close() directly instead of via
> the FwdState::closeServer() meth
On 05/06/2014 10:59 AM, Amos Jeffries wrote:
> On 7/05/2014 4:01 a.m., Alex Rousskov wrote:
>> On 05/06/2014 08:37 AM, Amos Jeffries wrote:
>>
>>> Several of the external ACL format codes have been added to
>>> Format::ByteCode_t without equivalent logformat
On 05/06/2014 08:37 AM, Amos Jeffries wrote:
> Several of the external ACL format codes have been added to
> Format::ByteCode_t without equivalent logformat TokenTableEntry's
> @ Format::Format::assemble(...)
> +// XXX: external_acl_type format codes are not yet output by this
> code
> +
On 05/02/2014 11:26 AM, Tsantilas Christos wrote:
> Looks that the attached patch should be enough to solve trunk with ecap
> build.
> If no problem I will apply to trunk.
Looks good to me. This should close item #3 on the to-do list, and Amos
has made great progress with #1 already.
Thank you,
On 05/01/2014 07:36 AM, Amos Jeffries wrote:
> On 1/05/2014 10:21 p.m., Tsantilas Christos wrote:
>> If I am not wrong, currently the protocol in HttpMsg::http_ver is
>> always AnyP::PROTO_HTTP.
>> I think this is normal because we are always handling HTTP messages.
> You are right. eCap not usin
On 05/01/2014 04:21 AM, Tsantilas Christos wrote:
> On 04/30/2014 09:33 PM, Alex Rousskov wrote:
>> libecap::FirstLine::protocol() is meant for things like
>>
>> * the HTTP-Version part of HTTP messages (in RFC 2616 terminology) or
>> * the ICAP-Version part of
On 04/30/2014 01:14 PM, Amos Jeffries wrote:
> On 1/05/2014 6:33 a.m., Alex Rousskov wrote:
>> On 28/04/2014 5:35 a.m., Tsantilas Christos wrote:
>>> Unfortunately this is not build with ecap.
>>
>>
>> On 04/27/2014 07:57 PM, Amos Jeffries wrote:
>>> W
On 28/04/2014 5:35 a.m., Tsantilas Christos wrote:
> Unfortunately this is not build with ecap.
On 04/27/2014 07:57 PM, Amos Jeffries wrote:
> What the eCAP field needs to be set to depends on its definition:
libecap::FirstLine::protocol() is meant for things like
* the HTTP-Version part of HT
On 04/29/2014 06:03 AM, Amos Jeffries wrote:
> I'm fine with "transferProtocol" or just "protocol" (although that may
> get as common as "conn" has become). Whichever suits you.
Let's avoid "protocol" for the reasons you mentioned and use
"transferProtocol".
>>> This variable can
>>> be altered
On 04/29/2014 05:48 AM, Amos Jeffries wrote:
> On 29/04/2014 8:46 a.m., Alex Rousskov wrote:
>> On 04/27/2014 10:02 PM, Amos Jeffries wrote:
>>
>>> We should state the problem with idles clearly (yes it is difficult to
>>> word),
>>
>> We already do th
On 04/28/2014 07:10 AM, Amos Jeffries wrote:
> * ssl-bump transforms the transportVersion from whatever it was
> previously (usually HTTP or HTTPS) to HTTPS.
> +/// the transport protocol currently being spoken on this connection
> +AnyP::ProtocolVersion transportVersion;
If I recall ou
On 04/27/2014 10:02 PM, Amos Jeffries wrote:
> We should state the problem with idles clearly (yes it is difficult to
> word),
We already do that:
> + max-conn limit works poorly when there is a relatively
> + large number of idle persistent connections wi
On 04/27/2014 06:09 AM, Amos Jeffries wrote:
> in cf.data.pre:
> * the new documentation for cache_peer max-conn= now states that idle
> connections count against teh limit
Yes, they do. The patch did not change that.
> then goes on to:
> "
> A peer exceeding the limit is not used for new
>
On 04/26/2014 01:59 AM, Amos Jeffries wrote:
> Also document HttpMsg::http_ver which is a copy of the HTTP-Version
> field in the "on-wire" message syntax. It is unrelated to the socket
> transport protocol and the URL scheme protocol.
I understand the above, but
> +/**
> + * The HTTP-Ve
On 04/25/2014 03:38 AM, Amos Jeffries wrote:
> On 25/04/2014 1:02 p.m., Alex Rousskov wrote:
>> Hello,
>>
>> The attached patch Various at-exit-time leaks removed to minimize
>> valgrind false positives.
>>
>> Removing these leaks helps with detecting
ientReplyContext::buildReplyHeader and friends).
Needless to say, there are exceptions and violations of the fundamental
principles sketched above.
HTH,
Alex.
> On Thursday, April 24, 2014 7:20 AM, Alex Rousskov wrote:
> On 04/24/2014 04:33 AM, Peter Belau wrote:
>
>
>> I'm tryi
Hello,
The attached patch Various at-exit-time leaks removed to minimize
valgrind false positives.
Removing these leaks helps with detecting true leaks, but it is possible
that these changes expose other bugs that crash exiting Squid. We have
not seen such crashes in our limited tests.
Some
cache_effective_user was leaking $HOME memory more than it had to.
Alex.
cache_effective_user was leaking $HOME memory more than it had to
=== modified file 'src/cache_cf.cc'
--- src/cache_cf.cc 2014-04-12 17:32:34 +
+++ src/cache_cf.cc 2014-04-24 20:23:43 +
@@ -874,44 +874,49 @@ configD
Do not leak ex_data for SSL state that survived reconfigure.
SSL_get_ex_new_index() allocates a new index on every call, even if its
parameters remain unchanged. It should be called once per process lifetime.
Besides leaking, this 12 year-old(!) bug could probably make some SSL
code misbehave dur
Do not leak fake SSL certificate context cache when reconfigure
changes port addresses.
Alex.
Do not leak fake SSL certificate context cache when reconfigure
changes port addresses.
=== modified file 'src/ssl/context_storage.cc'
--- src/ssl/context_storage.cc 2014-03-30 12:00:34 +
+++ src/ss
Do not leak [SSL] objects tied to http_port and https_port on reconfigure.
PortCfg objects were not destroyed at all (no delete call) and were
incorrectly stored (excessive cbdata locking). This change adds
destruction and removes excessive locking to allow the destructed
object to be freed. It al
Do not register the same Cache Manager action more than once, to avoid
wrong mgr:menu output and the impression of a reconfigure memory leak.
The old code was comparing action object pointers, which could not work,
and was adding the same action on every reconfigure call for modules
that register
Do not leak TcpAcceptor job on reconfiguration
by monitoring and reacting to the listening socket closure.
Every job that waits for Comm I/O must have a FD closure handler.
Unfortunately, we currently cannot enforce that rule automatically.
Alex.
Do not leak TcpAcceptor job on reconfiguration
by
Fixed a previously documented leak of ACLs related to adaptation access
rules.
Alex.
Fixed a previously documented leak of ACLs related to adaptation access rules.
=== modified file 'src/adaptation/AccessRule.cc'
--- src/adaptation/AccessRule.cc 2013-05-13 22:48:23 +
+++ src/adaptation/Acces
Do not leak implicit ACLs during reconfigure.
Many ACLs implicitly created by Squid when grouping multiple ACLs were
not destroyed because those implicit ACLs where not covered by the
global ACL registry used for ACL destruction.
See also: r13210 which did not go far enough because it incorrectly
Hello,
I am going to post several patches that fix various reconfiguration
leaks. The patches will be posted in no particular order. Here is a
Table of Contents:
1. implicit ACLs,
2. adaptation ACLs,
3. TcpAcceptor job,
4. Cache Manager menu items,
5. [SSL] objects tied to http_port
On 04/24/2014 04:33 AM, Peter Belau wrote:
> I'm trying to modify the Set-Cookie header from within
> client_side_reply.cc. Currently my code looks like this:
> HttpReply *rep = http->storeEntry()->getReply()->clone();
> http->storeEntry()->releaseRequest();
> rep->header.putStr(HDR_S
On 04/23/2014 05:36 AM, Amos Jeffries wrote:
> So,
> The internals of the library code (when enabled) can reference OpenSSL
> and/or the src/ssl/*.h objects as needed.
I am not sure that is a good rule. Maintaining an interface-level
separation of OpenSSL-reliant code from all other code would b
On 04/22/2014 03:01 AM, Michal Luscon wrote:
> I am wondering whether it would be possible to replace SQUID_MAXFD by
> Biggest_FD in the following code snippet from ipc.cc:
There are several problems with using Biggest_FD. In short, it is not
100% safe to use it now, and it is probably the wrong
On 04/21/2014 04:45 PM, Eliezer Croitoru wrote:
> Inquirer.cc:90: warning: 'auto_ptr' is deprecated (declared at
> /usr/include/c++/4.3/backward/auto_ptr.h:91)
> So first, What is the warning about and do you think we need to do
> something about it?
I think this deprecation warning is just like
On 04/20/2014 02:08 AM, Amos Jeffries wrote:
> +while ((rv = *left - *right++) == 0) {
> +if (*left++ == '\0' || --byteCount == 0)
> +break;
> +}
> +// If we stopped scanning because we reached the end of buf()
> +if (!byteCount && length() < n)
On 04/18/2014 12:12 PM, Amos Jeffries wrote:
> I see you are suggesting the FreeBSD libc strncmp() method
> http://fxr.watson.org/fxr/source/string/strncmp.c?v=FREEBSD6-LIBC
I have not seen that FreeBSD code before, and I do not think my sketch
is similar to it.
IIRC, my sketch is similar to th
On 04/17/2014 02:19 PM, Amos Jeffries wrote:
> On 17/04/2014 6:56 a.m., Alex Rousskov wrote:
>> On 04/16/2014 07:44 AM, Amos Jeffries wrote:
>>> +// x509 certificate credentials
>>> +gnutls_certificate_credentials_t certCredentials;
>>
>> client or s
On 04/17/2014 04:43 AM, Amos Jeffries wrote:
> On 17/04/2014 7:23 a.m., Alex Rousskov wrote:
>> Any reasonable/popular implementation selected by the developer. This is
>> a one-time check done by the developer, not an automated check done
>> during Squid build. Sorry I was
On 04/16/2014 12:30 PM, Amos Jeffries wrote:
> On 17/04/2014 2:32 a.m., Alex Rousskov wrote:
>> On 04/16/2014 12:05 AM, Amos Jeffries wrote:
>>> I don't see any way around this without hand-crafing a full byte-by-byte
>>> strncmp replacement.
>> I am not
On 04/16/2014 07:44 AM, Amos Jeffries wrote:
> Both CA verified and anonymous TLS are supported with CA verification
> being the default.
I cannot find "CA verified" term in RFC 5246. Is there a better term to
use? Is this about verifying the server certificate or the client
certificate? I assume
On 04/16/2014 12:05 AM, Amos Jeffries wrote:
> On 16/04/2014 5:07 a.m., Alex Rousskov wrote:
>> If I am reading the code correctly, there is a new bug:
>>
>>> It also avoids the s[] access by using strlen(s) != byteCompareLen.
>>
>>> +if (byteCompar
On 04/15/2014 08:55 AM, Amos Jeffries wrote:
> The attached patch passes all the tests including \0 embeded in the strings.
If I am reading the code correctly, there is a new bug:
> It also avoids the s[] access by using strlen(s) != byteCompareLen.
> +if (byteCompareLen < n && strlen(s) !
rock/RockSwapDir.cc. Look for SLOWLY_FILL_WITH_ZEROS.
Manual fill may slow down things a lot for large segments and slow disks
though. FWIW, a lot of documentation suggest ftruncate() as the right
solution here. We should resist manual fill if at all possible.
Cheers,
Alex.
> On Mon, Ap
On 04/14/2014 11:07 AM, Amos Jeffries wrote:
> On 15/04/2014 2:56 a.m., Alex Rousskov wrote:
>> On 04/14/2014 04:49 AM, Amos Jeffries wrote:
>>> I've added a unit test to catch the rare \0 mid-string case I spoke of:
>>> * SBuf("foo\0test").compare("
On 04/14/2014 01:01 PM, Kinkie wrote:
> The attached test program runs just fine on MacOS Mavericks; testRock
> fails, yet the code looks really the same as in src/ipc/mem/Segment.cc
> to me (after removing the O_TRUNC flag to shm_open).. can anyone spot
> a difference I can't see?
Perhaps strace
for 4-byte
> types on systems that support it.
AFAIK, there is no trunk module that both uses atomics and can work
without 64-bit atomics. Thus, splitting HAVE_ATOMIC_OPS into
HAVE_ATOMIC_OPS_32 and HAVE_ATOMIC_OPS_64 in trunk would be pointless. I
agree that such a split will be needed if such a
On 04/14/2014 04:49 AM, Amos Jeffries wrote:
> I've added a unit test to catch the rare \0 mid-string case I spoke of:
> * SBuf("foo\0test").compare("foo", 9);
>
> It works fine up to the point N(4) > strlen("foo"). After that point our
> function returns 1 to indicate that the SBuf is a longer s
On 04/13/2014 03:19 PM, Stuart Henderson wrote:
> On 2014-04-13, Alex Rousskov wrote:
>> On 04/13/2014 06:36 AM, Stuart Henderson wrote:
>>
>>> I'm just trying to build 3.5-HEAD on OpenBSD/i386 (i.e. 32-bit mode) for
>>> the first time. It fails due to use of
On 04/13/2014 06:36 AM, Stuart Henderson wrote:
> I'm just trying to build 3.5-HEAD on OpenBSD/i386 (i.e. 32-bit mode) for
> the first time. It fails due to use of 64-bit atomic ops:
>
> MemStore.o(.text+0xc90): In function `MemStore::anchorEntry(StoreEntry&, int,
> Ipc::StoreMapAnchor const&)':
On 04/10/2014 11:32 PM, Amos Jeffries wrote:
> I believe the attached patch is complete regarding the method conversion.
The patch looks OK to me. The comments below are minor and can be
ignored or fixed during commit.
> +sb.append(s.rawContent(), s.length());
> +
On 04/13/2014 05:13 AM, Amos Jeffries wrote:
>>> +/// comparison with a C-string
>>> +int compare(const char *s, SBufCaseSensitive isCaseSensitive, const
>>> size_type n) const;
>> ...
>>> +const size_type byteCompareLen = min(n, length());
>>> +++stats.compareSlow;
>>> +int rv
On 04/12/2014 07:59 AM, m.shahve...@ece.ut.ac.ir wrote:
> In FwdState constructor code, why is the store entry locked and when is it
> unlocked?
The store entry is locked to prevent its destruction during FwdState
lifetime. The store entry locked in FwdState constructor is unlocked in
FwdState de
" ?= " <<
> right;
> +CPPUNIT_ASSERT_EQUAL(sign(strcasecmp(left, right)),
> sign(SBuf(left).caseCmp(right)));
> +//std::cerr << std::endl << " caseCmp(SBuf) npos " << left << " ?= " <<
> right;
> +CPPUN
On 04/10/2014 05:47 AM, Amos Jeffries wrote:
> New patch attached.
> This clears up the requests from both of you.
Not all of them, and there is also a new serious bug. Details below.
Old stuff:
* The usually needless SBuf allocation for common methods is still there:
> +SBuf str(begin, e
On 04/07/2014 09:45 PM, Amos Jeffries wrote:
>
> Add mk-sbuf-strings.awk script to produce a global array of SBuf for the
> string objects of registered methods. This can be re-used to convert
> other enum name arrays as we go forward.
>
> Use an SBuf to store unknown method names "image". Includ
On 04/08/2014 09:28 AM, Tsantilas Christos wrote:
> Alex analysis for the crashes is correct. However I believe that we
> should try fixing the crashes, not be back to squid Vector. Or even if
> we go back to squid Vector, we still need to fix this problem.
> The Squid Vector, just hides the prob
On 04/05/2014, Amos Jeffries wrote on #squidev:
> the issue I'm most stuck at is design decision on how to represent cachemgr
> tables in YAML format.
> the CGI uses TSV (tab separated values) for the block of lines in a table.
> YAML seems less friendly.
> I have found that line format " - [
On 04/02/2014 05:03 AM, Amos Jeffries wrote:
> This removes the needless Comm::ConnectionList* parameter to the PSC
> (Peer Select callback) function.
>
> The callee state object (data) of PSC is the original owner of the
> vector "list" being returned so always has direct access to it as a
> memb
getting this change
committed, especially since significant changes were required to the
initial submission. For the future, perhaps we can adjust the
commit-after-objections rules to avoid such situations.
Alex.
On 16/03/2014 1:08 a.m., Amos Jeffries wrote:
On 9/03/2014 7:34 p.m., Alex
of my comments should apply to Squid2 and Squid3, but please do not
expect v2.7 patches to be officially accepted (or even reviewed).
HTH,
Alex.
> On Friday, 14 March 2014 8:51 PM, Alex Rousskov wrote:
> On 03/13/2014 11:46 PM, aditya agarwal wrote:
>
>> We have a set of new req
ts me to it.
Thank you,
Alex.
On 03/04/2014 11:44 AM, Nikolai Gorchilov wrote:
> On Tue, Mar 4, 2014 at 7:50 PM, Alex Rousskov wrote:
>> On 03/04/2014 09:44 AM, Nikolai Gorchilov wrote:
>>> On Tue, Mar 4, 2014 at 6:01 PM, Alex Rousskov wrote:
>>>> On 03/03/201
Hello,
I have discovered one difference between std::vector and Squid's own
Vector implementation that might explain some of the random crashes that
some of us have been seeing after the Vector class was replaced with
std::vector in trunk.
Squid Vector sets the number of stored elements to ze
On 03/14/2014 02:36 AM, Eliezer Croitoru wrote:
> Adding a domain or acl test for internal squid StoreID feature to allow
> it run faster but with a patch to the sources.
>
> I was thinking about adding the code to the StoreID reply section on a
> ERR case while another flag is being used to allow
2.7.
Could have been worse!
HTH,
Alex.
> On Thursday, 13 March 2014 11:13 PM, Alex Rousskov
> wrote:
> On 03/13/2014 09:52 AM, aditya agarwal wrote:
>
>> We had already thought of the second option to fetch the objects at
>> regular intervals so that they are alway
On 03/12/2014 12:40 PM, Eliezer Croitoru wrote:
> On 12/03/2014 01:12, Alex Rousskov wrote:
>>> >--- src/http.cc 2014-03-07 15:40:37.945321671 +0200
>>> >+++ src/http.cc 2014-03-07 15:41:36.853321533 +0200
>>> >@@ -2106,7 +2106,7 @@
>>> > H
The patch pasted below is related to a long discussion on squid-users.
See the "ICP and HTCP and StoreID" thread there.
On 02/14/2014 04:38 AM, Nikolai Gorchilov wrote:
> On Fri, Feb 14, 2014 at 7:22 AM, Alex Rousskov wrote:
>> On 02/13/2014 06:05 PM, Nikolai Gorchilov
On 03/10/2014 03:19 PM, Amos Jeffries wrote:
> Okay. Is this better?
[TCP_TUNNEL]
> - traffic for which Squid is not able to act as a proxy. The
> transaction payload/body was tunneled as raw binary to the server.
TCP_RELAY
- for requests which Squid serves without even consider
On 03/10/2014 03:50 PM, Amos Jeffries wrote:
> I've been searching for some time for a crypto library that provides
> algorithms like base64, MD4, MD5, SHA* etc that are used by Squid. So we
> can remove the bundled re-implementations and avoid some big issues like
> FIPS compliance of Squid.
>
>
On 03/08/2014 04:13 AM, Amos Jeffries wrote:
> Prepare the way to efficiently parse client requests using SBuf based
> parser-ng.
>
> We rely on several guarantees for this to work:
>
> * rawSpace(N) guarantees that the backing store is both unique to this
> SBuf and has at least N bytes of unus
On 03/07/2014 06:26 PM, Amos Jeffries wrote:
> TCP_TUNNEL
>
> - initially for CONNECT requests which Squid serves Direct. Also to be
> used in future if Squid accepts an Upgrade request for protocols like
> WebSockets
>
>
> TCP_RELAY
>
> - for requests which Squid serves without even consid
On 03/07/2014 11:04 AM, Nikolai Gorchilov wrote:
> Dear Squid Devs,
>
> In order to simplify an already complicated squid config I needed a
> negative boolean check like this:
> if ${process_number} != 1
> ... do something in case this is NOT kid1
> endif
The "else" clause is also supported, but
will sketch the diagram here as a teaser for the
detailed explanation and the end of the discussion that follows:
SideAgent->ClientAgent->HttpClient<-HttpAgent<-ProtoAgent
SideAgent->ServerAgent->HttpServer<-HttpAgent<-ProtoAgent
On 03/04/2014 06:23 PM, Amos Jeffries wrote
' HttpClient. This is just a feeling/speculation on my point, but if
I am right it would explain a lot of arguments :-).
The next portion of this email is about the overall approach to this
(and similar) reviews. Detailed discussion follows that.
> On 2014-03-04 07:23, Alex Rousskov wro
On 03/04/2014 09:44 AM, Nikolai Gorchilov wrote:
> On Tue, Mar 4, 2014 at 6:01 PM, Alex Rousskov
> wrote:
>> On 03/03/2014 04:03 PM, Niki Gorchilov wrote:
>>
>>> FATAL: Squid has attempted to read data from memory that is not
>>> present. This is an indicat
On 03/03/2014 04:03 PM, Niki Gorchilov wrote:
> FATAL: Squid has attempted to read data from memory that is not
> present. This is an indication of of (pre-3.0) code that hasn't been
> updated to deal with sparse objects in memory. Squid should
> coredump.allowing to review the cause.
I have seen
iewed, polished, and committed.
Discussion follows.
On 03/03/2014 04:03 AM, Amos Jeffries wrote:
> On 3/03/2014 10:27 a.m., Alex Rousskov wrote:
>> I think we still disagree on what Agent is, unfortunately (and, hence,
>> what your TcpReceiver is). I think you are currently not writing an
I suggest to pick one of the following options as the next step:
(A) Make TcpReceiver into a base Agent class as defined below. If this
approach results in significant code duplication, encapsulate duplicated
code into a yet unnamed class(es), such as a class discussed in (B).
This encapsulation i
On 03/01/2014 02:55 AM, Amos Jeffries wrote:
> On 1/03/2014 5:23 p.m., Alex Rousskov wrote:
>> Agent: Common base for Client and Server agents. Uses Transport.
>> Client: Common base for HttpClient, FtpClient, IcapClient, etc.
>> Server: Common base for HttpS
On 02/08/2014 04:00 AM, Amos Jeffries wrote:
> On 8/02/2014 8:05 p.m., Alex Rousskov wrote:
>> Agent will have pure virtual functions, of course. Event the existing
>> ClientAgent (i.e., ServerStateData) does!
> Oh you are looking at Agent as part of the hard-coded inherite
On 02/28/2014 01:46 PM, Francesco wrote:
> But since this is a question on the standard, why don't we simply ask
> to the standard-setting body what their interpretation is?
The standard does not say what the proxy must do with malformed requests
that we are discussing. You can certainly get opin
On 02/28/2014 12:28 AM, Amos Jeffries wrote:
> Please look at what decideIfWeDoRanges() already does to the server traffic.
> Under your proposal to ignore Request-Range and treat Range normally
That was not my proposal.
> Squid will newely become a client emitting only Request-Range whenever
>
On 02/27/2014 02:57 PM, Amos Jeffries wrote:
> On 2014-02-28 04:58, Alex Rousskov wrote:
>> On 02/27/2014 12:58 AM, Amos Jeffries wrote:
>>
>>>>> FWIW: the specification says any proxy MAY drop Range at its choice.
>>
>> Where does it say that? I do not se
On 02/27/2014 12:58 AM, Amos Jeffries wrote:
>>> FWIW: the specification says any proxy MAY drop Range at its choice.
Where does it say that? I do not see such language in Section 3.1 of
draft-ietf-httpbis-p5-range-26. There is a "MAY reject" clause, but
rejection implies a 416 error response rat
On 02/26/2014 09:51 PM, Amos Jeffries wrote:
> While checking the code against HTTPbis Range draft I think we have a
> possible smuggling avenue being enabled by Squid in the form of the
> Request-Range header.
>
> What I can see there in Squid is parsing Request-Range into the same
> memory struc
On 02/20/2014 06:03 PM, Amos Jeffries wrote:
> On 20/02/2014 3:47 p.m., Alex Rousskov wrote:
>> On 02/16/2014 08:42 PM, Amos Jeffries wrote:
>>> On 17/02/2014 2:56 p.m., Alex Rousskov wrote:
>>>> If my suggestion to add shutdown() and other methods to runners is
>
On 02/21/2014 03:23 AM, Nikolai Gorchilov wrote:
> On Fri, Feb 21, 2014 at 7:24 AM, Alex Rousskov
> wrote:
>> On 02/08/2014 11:24 AM, Nikolai Gorchilov wrote:
>>
>>> Unfortunately, the rock store issue I've found isn't related to r13201
>>> regr
On 02/08/2014 11:24 AM, Nikolai Gorchilov wrote:
> Unfortunately, the rock store issue I've found isn't related to r13201
> regression as presumed by Amos.
>
> It's still available with both stable (3.4.x) and development
> (3.HEAD) branches.
Indeed. If you can, please try the attached trunk pa
101 - 200 of 2666 matches
Mail list logo
