Search squid archive

Re: Squid network read()'s only 2k long?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 2 Nov 2010 00:55:38 +0000, Declan White <declanw@xxxxxxxxxxxx>
wrote:
> On Tue, Nov 02, 2010 at 12:10:25AM +0000, Amos Jeffries wrote:
>> On Mon, 1 Nov 2010 22:55:12 +0000, Declan White <declanw@xxxxxxxxxxxx>
>> wrote:
>> > On Mon, Nov 01, 2010 at 09:36:53PM +0000, Amos Jeffries wrote:
>> >> On Mon, 1 Nov 2010 15:00:21 +0000, declanw@xxxxxxxxxxxx wrote:
>> 
>> Looks like one of the side effects of 3090:
>> http://www.squid-cache.org/Versions/v3/3.1/changesets/
>> 
>> (just fixing the reply text makes squid produce a regular error page
>> where
>> it should have produced an auth challenge to get some usable Basic-auth
>> credentials).
> 
> Ah, does that mean there's a cleaner fix somewhere I should be stealing?

Yes. The patch at that link I gave.

> 
>> 64KB is about the buffer size Squid uses internally, so that is about
>> right for keeping a completely full buffer I think.
> 
> Is there any wisdom in me subtracting a few bytes to account for some
> memory overhead anywhere?

Not sure. The overheads I'm aware of are accounted separate form the
actual buffers already.

>  
> By the by, I *think* I've gotten to the bottom of my 2046 byte read()
> buffer
> issue (which wasn't tcp_recv_bufsize after all). *If* I am reading this
> right:
> 
> http.cc:79: HttpStateData::HttpStateData 
>     readBuf = new MemBuf;
>     readBuf->init();
> 
> With no arguments, init() will cook up an empty 2048 size buffer, which
> gets
> carried all the way through the OO to the read() call (wherever that is)
> that dutifully only reads as much as the buffer says it currently has.
> 
> So I'm thinking of hardwiring something in there tomorrow and seeing
what
> explodes.

I agree. Came to the same conclusion. It *should* be exponentially grown
so the read are 2K, 2K, 4K. But that 4K seems not to happen.


> 
>> Okay. I think from the resource comments above you want it OFF. Squid
>> will
>> respond to HTTP/1.1 "Expect:" requests immediately and broken clients
>> that
>> can't handle the required HTTP/1.1 replies disappear with error pages.
> 
> Ah, by 'broken clients' are we talking IE6 by any chance? :)

PDF readers and java applets mostly that I've heard of.

Amos


[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux