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

Robert Collins

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


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

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.