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

Branch merges

Propose for merging

No branches dependent on this one.

Related source package recipes

No recipes using this branch. (?)

Create packaging recipe

Related snap packages

Related bugs

Related blueprints

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.