sendMoreData without connection

[Alex Rousskov]

Hello,

Could somebody explain whether the connection can be missing in the
sendMoreData trunk code below, please?

void
clientReplyContext::sendMoreData (StoreIOBuffer result)
{
if (deleting)
return;

StoreEntry *entry = http->storeEntry();

ConnStateData * conn = http->getConn();

int fd = conn != NULL ? conn->fd : -1;
...


I know that the connection can be in a closing state. In that case, the
new code will simply quit sendMoreData because there is nobody to send
the data to.

I am tempted to do the same for the missing conn case, but it looks like
the old code implies it could be a valid case and sendMoreData should
not quit. Is NULL conn a valid case? If yes, is it appropriate to handle
it by simply returning from the method?

Thank you,

Alex.
P.S. Current USE_ZPH_QOS code in sendMoreData may crash and burn of conn
is missing.

Squid-2.HEAD URL regression with CONNECT

[Adrian Chadd]

G'day,

Squid-2.HEAD doesn't seem to handle CONNECT URLs anymore; I get something like:

[start]
The requested URL could not be retrieved

While trying to retrieve the URL: www.gmail.com:443

The following error was encountered:

* Invalid URL
[end]

Benno, could you please double/triple check that your method and url
related changes to Squid-2.HEAD didn't break CONNECT?

Thanks!


Adrian

Re: [PATCH] Send 407 on url_rewrite_access/storeurl_access

[Amos Jeffries]

Amos Jeffries has voted reject.
Status is now: Vetoed
Comment:
Squid-2 patch. not for BB to handle.

For details, see: 
http://bundlebuggy.aaronbentley.com/project/squid/request/%3C20080907005501.GB8733%40motherbox.xtech.com.ar%3E

Project: Squid

Re: /bzr/squid3/trunk/ r9176: Fixed typo: Config.Addrs.udp_outgoing was used for the HTCP incoming address.

[Henrik Nordstrom]

On tis, 2008-09-09 at 14:59 +1200, Amos Jeffries wrote:
> > 
> > revno: 9176
> > committer: Alex Rousskov <[EMAIL PROTECTED]>
> > branch nick: trunk
> > timestamp: Mon 2008-09-08 17:52:06 -0600
> > message:
> >   Fixed typo: Config.Addrs.udp_outgoing was used for the HTCP incoming
> > address.
> > modified:
> >   src/htcp.cc
> >
> 
> I think this is one of those cleanup situations where we wanted to split
> the protocol away from generic udp_*_address and make it an
> htcp_outgoing_address. Yes?

Yes.

The udp_ and tcp_ all need to die a painful death.

Regards
Henrik


signature.asc
Description: This is a digitally signed message part

Re: How to buffer a POST request

[Adrian Chadd]

Well, I've got a proof of concept which works well but its -very-
ugly. This is one of those things may have been slightly easier to do
in Squid-3 with Alex's BodyPipe changes. I haven't stared at the
BodyPipe code to know whether its doing all the right kinds of
buffering for this application.

The problem is that Squid-2's request body data pipeline doesn't do
any of its own buffering - it doesn't do anything at all until a
consumer says "give me some more request body data please" at which
point its copied out of conn->in.buf (the client-side incoming socket
buffer), consumed, and passed onto the caller.

I thought about a "clean" implementation which would involve the
request body pipeline code consuming socket buffer data until a
certain threshold is reached, then feeding that back up to the request
body consumer but I decided that was too difficult for this particular
contract.

Instead, the "hack" here is to just keep reading data into the
client-side socket buffer - its already doing double duty as a request
body buffer anyway - until an ACL match fires to begin forwarding. Its
certainly not clean but it seems to work in local testing. I haven't
yet tested connection aborts and such to make sure that connections
are properly cleaned up.

I'll look at posting a patch to squid-dev in a day or two once my
client has had a look at it.

Thanks,



Adrian


2008/8/8 Adrian Chadd <[EMAIL PROTECTED]>:
> Well I'm still going through the process of planning out what changes
> need to happen.
>
> I know what changes need to happen long-term but this project doesn't
> have that sort of scope..
>
>
>
> Adrian
>
> 2008/8/8 Mark Nottingham <[EMAIL PROTECTED]>:
>> You said you were doing it :)
>>
>>
>> On 08/08/2008, at 4:40 PM, Adrian Chadd wrote:
>>
>>> Way to dob me in!
>>>
>>>
>>> Adrian
>>>
>>> 2008/8/8 Mark Nottingham <[EMAIL PROTECTED]>:

 I took at stab at:
 http://wiki.squid-cache.org/Features/RequestBuffering


 On 22/07/2008, at 4:40 PM, Henrik Nordstrom wrote:

> It's not a bug. A feature request in the wiki is more appropriate.
>
> wiki.squid-cache.org/Features/
>
> Regards
> Henrik
>
> On mån, 2008-07-21 at 17:50 -0700, Mark Nottingham wrote:
>>
>> I couldn't find an open bug for this, so I opened
>> http://www.squid-cache.org/bugs/show_bug.cgi?id=2420
>>
>>
>> On 11/06/2008, at 3:29 AM, Henrik Nordstrom wrote:
>>
>>> On ons, 2008-06-11 at 12:51 +0300, Mikko Kettunen wrote:
>>>
 Yes, I read something about this on squid-users list, there seems
 to be
 8kB buffer for this if I understood right.
>>>
>>> The buffer is bigger than that. But not unlimited.
>>>
>>> The big change needed is that there currently isn't anything delaying
>>> forwarding of the request headers until sufficient amount of the
>>> request
>>> body has been buffered.
>>>
>>> Regards
>>> Henrik
>>
>> --
>> Mark Nottingham   [EMAIL PROTECTED]
>>

 --
 Mark Nottingham   [EMAIL PROTECTED]



>>
>> --
>> Mark Nottingham   [EMAIL PROTECTED]
>>
>>
>>
>