lp:~lifeless/squid/3.1-ext-tag

Created by Robert Collins on 2012-06-13 and last modified on 2012-06-13
Get this branch:
bzr branch lp:~lifeless/squid/3.1-ext-tag
Only Robert Collins can upload to this branch. If you are Robert Collins please log in for upload directions.

Branch merges

Related bugs

Related blueprints

Branch information

Owner:
Robert Collins
Project:
Squid
Status:
Development

Recent revisions

10456. By Robert Collins on 2012-06-13

Backport the EXT_TAG external acl support.

10455. By Amos Jeffries on 2012-06-08

3.1.20

10454. By Christos Tsantilas on 2012-06-05

Bug 3013: segmentation fault on shutdown commSetCloseOnExec at comm.cc:1889

10453. By Amos Jeffries on 2012-06-05

Bug 3233: Invalid URL accepted with url host is white spaces

10452. By Fyodor <email address hidden> on 2012-06-05

Bug 3074: Improper URL handling with empty path (RFC 3986)

10451. By Christos Tsantilas on 2012-06-05

Bug 3463: dnsserver fails to compile

10450. By Francesco Chemolli on 2012-06-05

Bug 3390: Proxy auth data visible to scripts

10449. By Francesco Chemolli on 2012-06-05

Extend g++ compatibility for extern inline functions

10448. By Marcin Wisnicki <email address hidden> on 2012-05-30

Bug 3545: FreeBSD dnsserver segfaults

10447. By Alex Rousskov on 2012-05-29

Bug 3466: Adaptation stuck on last single-byte body piece

Changed StoreEntry::bytesWanted(range) to return range.end when the entry can
accommodate range.end bytes. This makes it possible to use that method for
single-byte ranges. Old code returned zero for such ranges, which was
difficult to distinguish from situations where no bytes were wanted at all.

TODO: The StoreEntry::bytesWanted(range) API is left undocumented because it
seems to be slightly broken and/or inconsistent with callers and with the
DelayId::bytesWanted(min, max) API. AFAICT, we should convert
StoreEntry::bytesWanted API from range-based to min/max-based or even just
max-based.

Store Entry API does not use the lower end of the range (except for the
now-removed assertion that the range is not empty). I suspect that Store API
was meant to be used with (first, last+1) "byte position" parameters (returning
the number of bytes wanted) while the DelayId API was meant to be used with
(min, max) "number of bytes" parameters. However, StoreEntry::bytesWanted
implementation does not follow this assumption so perhaps my speculation is
wrong and there are more problems, including this change.

Branch metadata

Branch format:
Branch format 6
Repository format:
Bazaar pack repository format 1 (needs bzr 0.92)
This branch contains Public information 
Everyone can see this information.

Subscribers