Amos Jeffries [Sun, 8 Aug 2010 02:12:50 +0000 (14:12 +1200)]
Make FTP able to retry after stupid FTP-protocol errors.
It only really matters if PUT/POST body data was sent to the server
Or if any reply headers/data was sent to the client.
For the relative long and error-prone state in between starting to FTP
connect and actually sending the data we can retry different FTP data
setup methods and forwarding paths forever.
Bug fix: In the case of an error while accessing a gopher server, squid will crash
The GopherStateData::req used to retrieve the releated HttpRequest object in
gopherSendComplete function when a server while accessing the server occurs.
The GopherStateData::req is never assigned and it is always NULL (should be
removed?). The gopherState->fwd->request must be used instead.
Author: Tsantilas Christos <chtsanti@users.sourceforge.net> , Alex Rousskov <rousskov@measurement-factory.com>
Added %http::<bs and %icap::<bs logformat codes to HTTP and ICAP body sizes received from the next HTTP hop or the ICAP server.
Logging "received message body" is useful because Squid may receive a lot
more or a lot less than it serves to the client or than the original resource
size, which may happen when handling Range requests and partial responses,
when adapting bodies, and for other reasons.
For HTTP, we define "received message body" as message body bytes that
Squid stores, merges, adapts, and/or forwards. In most cases, they are the
same as body bytes sent by the server to Squid. However, the two bodies may
differ for reasons such as errors (where the start of the body was not found),
HTTP transfer encodings (where Squid strips chunked encoding to find the
message body), and generated FTP directory listings (that were received in
a completely different format on a control connection).
For ICAP, the "received message body" is the Encapsulated sections, after
the encapsulated HTTP body, if any, is dechunked.
Solaris 9 is not fully RFC 3493 compliant. It does not provide the
IPV6_V6ONLY even as a null-op option.
There are potentially other systems in the same situation. Fix is to
detect the absence of the option and fall back to split-stack on
IPv6-enabled systems without it.
Alex Rousskov [Mon, 2 Aug 2010 16:43:03 +0000 (10:43 -0600)]
Compliance: Improved HTTP Range header field validation.
1) Improved HttpHdrRangeSpec::parseInit() to parse syntactically valid
range specs:
* Suffix ranges with 0 length (i.e. -0) are syntactically valid.
* Check that last-byte-pos is greater than or equal to first-byte-pos.
After the change, HttpHdrRangeSpec::parseInit() successfully parses suffix
ranges with 0 length. They were rejected before. RFC 2616 section 14.35.1 says
such range specs are syntactically valid but unsatisfiable. Thus, we should
ignore the range spec itself, but not the whole range header. These range
specs will be rejected later, during canonization.
2) In HttpHdrRangeSpec::parseInit(), ignore the whole range header if one of
range specs is syntactically invalid (i.e. range spec parsing fails).
Co-Advisor test case: test_clause/rfc2616/invalidRange
Amos Jeffries [Sun, 1 Aug 2010 06:16:06 +0000 (18:16 +1200)]
Basic split-stack functionality
Enable split-stack detection by default.
There is now enough split-stack support to enable accepting IPv6 client
connections on systems with separate IPv4/IPv6 stacks. Also some limited
server connection capabilities (see tcp_outgoing_addr config hacks).
SNMP, ICP, HTCP listeners and outbound connections currently default to
IPv4-only on these systems to retain backward-compatibility.
But may be explicity configured to IPv6-only. There is no support as yet
for dual-protocol behaviour in the sockets of these three protocols.
This hack was removed during the libtool 2.2 upgrade.
The issue shows up as bundle builds failing to link libltdl/libltdlc.la
when they should in fact be linking ../libltdl/libltdlc.la in src/Makefile
It is caused by the macros of libtool 2.2 assuming the presence of
top_build_prefix but since autoconf 2.62 that was replaced with
ac_top_build_prefix and is no longer automatically defined in Makefile's.
Some distros also seem to have back-ported the removal of top_build_prefix
into their old autoconf causing macro version tests to fail.
httpHdrCcParseInit() ignored all unknown Cache-Control directives
except for the first one because the (type != CC_OTHER) check
applied to the debugging statement only.
Co-Advisor test case: test_case/rfc2616/endHdr-fwd-set-Cache-Control-toSrv
Bug 2994: pt 1: Open *_port directives correctly in IPv4-only mode.
Was opening snmp_port, icp_port, htcp_port under the v4-mapping assumption.
This forces the ports both listening and outgoing to IPv4-only unless
v4-mapping is actually available in the system.
Bug fix: 32bit integer used in HttpStateData to store the bytes received from next hop
A simple integer used to store the bytes received from the next hop
(http server of proxy), which my cause problems when receives huge
http objects on 32bit systems.
Bug fix: The bytes sent/received to/from the ICAP server may not logged correctly on 32bit systems
A simple long int (doint/outint) used to log bytes sent/received to/from
the ICAP server, ICAP requests with very large http objects will not
logged correctly. Use int64_t (dooff/outoff) instead
Replace most USE_IPV6 with run-time support probing
This unifies the code built for IPv4-only, dual-stack and split-stack.
* --disable-ipv6 option remains, however it now prevents the run-time probe
* Probing previously done in ./configure at build time is now merged and
performed run-time on every startup. IPv6 is enabled or disabled based on
the underlying OS support for sockets and setsockopt operations required.
* Parsing and other operations which can be performed without specific IPv6
connectivity are enabled.
* Some DNS logic alterations have had to be made to merge the split-stack
DNS and leverage it for IPv4-only mode. Otherwise the logics are unchanged
from previous dual-stack builds which have been well tested.
Client side must stop reading when switching to a tunnel mode. The old code
called low-level commSetSelect to stop reading, but that left Comm tables in
an inconsistent state, with the client side reader callback still scheduled.
Squid would assert when the tunnel called comm_read with its own callback.
The bug is unrelated to half-closed connections despite halfClosedReader
mentioned in the assertion text. The assertion means "no more than one active
reader per FD".
projects / thirdparty / squid.git / log
