Amos Jeffries [Sat, 23 Oct 2010 13:43:17 +0000 (07:43 -0600)]
Author: Alex Rousskov <rousskov@measurement-factory.com>
HTTP Compliance: do not cache replies to requests with CC/no-store.
Per RFC 2616, do not store any part of response to requests with a no-store
Cache-Control directive.
We may still _serve_ no-store requests from the cache because RFC 2616 does not
seem to prohibit that. This may change if HTTPbis or developers decide to
prohibit no-store hits.
Co-Advisor test case:
test_case/rfc2616/ccReqDirMsg-no-store-basic
Amos Jeffries [Sat, 23 Oct 2010 13:42:20 +0000 (07:42 -0600)]
Author: Alex Rousskov <rousskov@measurement-factory.com>
HTTP Compliance: reply with 504 (Gateway Timeout) if required validation fails.
RFC 2616 says that we MUST reply with 504 (Gateway Timeout) if validation
fails and cached reply has proxy-revalidate, must-revalidate or s-maxage
Cache-Control directive.
FwdState::makeConnectingError() method is added to set error status depending
on whether the request was a validation request.
Co-Advisor test cases:
test_case/rfc2616/noSrv-hit-must-reval-s-maxage-resp
test_case/rfc2616/noSrv-hit-must-reval-proxy-revalidate-resp
test_case/rfc2616/noSrv-hit-must-reval-must-revalidate-resp
Amos Jeffries [Sat, 23 Oct 2010 13:41:01 +0000 (07:41 -0600)]
Author: Alex Rousskov <rousskov@measurement-factory.com>
HTTP Compliance: support requests with Cache-Control: min-fresh.
Added min-fresh directive support for Cache-Control header. The directive is
handled in refreshCheck() by incrementing age and check_time by min-fresh
value.
Co-Advisor test case:
test_case/rfc2616/ccReqDirMsg-min-fresh-obey
Amos Jeffries [Sat, 23 Oct 2010 13:39:03 +0000 (07:39 -0600)]
Author: Alex Rousskov <rousskov@measurement-factory.com>
HTTP Compliance: add appropriate Warnings if serving a stale hit.
Per RFC 2616, we MUST add "110 Response is stale" Warning if serving a
stale reply for any reason, including configured overrides. We MUST add
"111 Revalidation failed" Warning if serving a stale reply because an
attempt to revalidate the response failed, due to an inability to reach
the server.
The patch adds a new stale_if_hit request flag, which is set in
refreshCheckHTTP() when entry freshness is calculated. refreshCheckHTTP()
is now called in offline mode, to set stale_if_hit properly. We check for
the offline mode before returning from refreshCheckHTTP() to preserve the
original logic.
refreshCheckHTTP() is no longer called for internal requests, to avoid
setting of stale_if_hit flag. It did not do anything important for
internal requests anyway.
Co-Advisor test cases:
test_case/rfc2616/noSrv-hit-stale-max-age-req
test_case/rfc2616/ccReqDirMsg-max-stale-warning
Amos Jeffries [Sat, 23 Oct 2010 13:36:27 +0000 (07:36 -0600)]
Author: Alex Rousskov <rousskov@measurement-factory.com>
Accept ICAP OPTIONS responses with unknown body types.
Warn about the unknown OPTIONS body type but ignore it instead of rejecting
the entire OPTIONS response. Note that ICAP does not standardize OPTIONS
body types, and Squid does not recognize any body type.
ICAP servers are supposed to negotiate the use of OPTIONS bodies but
negotiation mechanism is not standardized and some do not negotiate at all.
Amos Jeffries [Sat, 23 Oct 2010 13:29:15 +0000 (07:29 -0600)]
Author: Alex Rousskov <rousskov@measurement-factory.com>
HTTP Compliance: Reply with an error if required validation fails.
RFC 2616 says that proxy MUST not use stale entries that have s-maxage,
proxy-revalidate, or must-revalidate cache-directive.
Add new fail_on_validation_err request flag to store result from
refreshCheck(). It is needed to avoid refreshLimits() recalculation in
clientReplyContext::handleIMSReply().
Split LOG_TCP_REFRESH_FAIL into LOG_TCP_REFRESH_FAIL_OLD (stale reply sent)
and LOG_TCP_REFRESH_FAIL_ERR (error forwarded). However, both are still logged
as TCP_REFRESH_FAIL for backward-compatibility with external scripts and such.
We may decide to start logging more detailed codes later.
Co-Advisor test cases:
test_case/rfc2616/noSrv-hit-must-reval-s-maxage-resp
test_case/rfc2616/noSrv-hit-must-reval-proxy-revalidate-resp
test_case/rfc2616/noSrv-hit-must-reval-must-revalidate-resp
Amos Jeffries [Wed, 20 Oct 2010 06:09:27 +0000 (00:09 -0600)]
Author: Alex Rousskov <rousskov@measurement-factory.com>
Cleanup: Remove old_rep2 from clientReplyContext::handleIMSReply().
StoreEntry::getReply() returns pointer to HttpReply that belongs to MemObject.
It does not create a new object. Hence, outer old_rep, inner old old_rep, and
inner new old_rep2 in handleIMSReply() are equal.
Amos Jeffries [Wed, 20 Oct 2010 06:06:14 +0000 (00:06 -0600)]
Author: Alex Rousskov <rousskov@measurement-factory.com>
HTTP Compliance: Make date parser stricter to better handle malformed Expires.
Check that there is no zone or zone is "GMT" in parse_date_elements().
Make sure there is no junk at the end of date in parse_date().
This will affect Date, IMS, and other date-carrying header fields recognized
by Squid but should not cause any messages to be rejected. Squid would just
ignore the malformed headers as if they are not there.
Co-Advisor test case:
test_case/rfc2616/invalidExpiresMakesStale-rfc1123x
Amos Jeffries [Wed, 20 Oct 2010 05:25:13 +0000 (23:25 -0600)]
Author: Alex Rousskov <rousskov@measurement-factory.com>
Prohibit fruitless modification of httpBuildRequestHeader flags parameter.
HttpStateData::httpBuildRequestHeader is a static method, but it has a
parameter called flags, just like HttpStateData objects have a data member
called flags. Modifying that parameter "worked" but had no effect on the
caller's flags. Wasted a few good hours.
The parameter is "const" now, to prevent fruitless modification.
Also removed http_state_flags parameter from HttpStateData::buildRequestPrefix
which is not a static method and has access to the "real" flags member.
No runtime effect expected.
TODO: Rename HttpStateData::httpBuildRequestHeader to mark its static nature.
Does it belong to HttpStateData at all?
Amos Jeffries [Wed, 20 Oct 2010 05:21:34 +0000 (23:21 -0600)]
Author: Alex Rousskov <rousskov@measurement-factory.com>
Handle ICAP persistent connection races better.
When an ICAP transaction loses a persistent connection race with an ICAP
server (i.e., Squid sends the ICAP request on a persistent connection just
closed by the ICAP server), the transaction throws and the exception is
treated as a regular error. Even though the transaction may be retried, the
negative side-effects may include ICAP service suspension due to transaction
failures.
This patch logs ICAP transactions that fail due to pconn races with
ERR_ICAP_RACE status and does _not_ blame the ICAP service for the failure.
The following problem was exposed by the pconn races but its fix is
useful in other scopes as well:
When the ICAP connection times out, we now close the connection before
throwing because an exception may be bypassed, and we will throw again (during
peaceful bypass) if Comm tells us that the connection is ready after we timed
out (yes, that can happen because Comm timeouts do not auto-close the
connection).
Amos Jeffries [Wed, 20 Oct 2010 05:13:44 +0000 (23:13 -0600)]
Author: Alex Rousskov <rousskov@measurement-factory.com>
Keep ICAP connection persistent after an OPTIONS response if possible.
Old OptXact code used Xaction::doneReading() which was only true at EOF.
Thus, closeConnection() was thinking we are still reading (i.e., not
doneWithIo) at the end of the transaction and force-closed the connection.
New OptXact implements its own doneReading() which returns true at EOF and
when we read the entire response. Since we cannot parse OPTIONS body and
do not know where it ends, OPTIONS responses with bodies still result in
connection closure. We should not be getting any, but there are broken ICAP
servers that do send them. Hopefully, they all use Encapsulated: opt-body.
Amos Jeffries [Wed, 20 Oct 2010 05:03:14 +0000 (23:03 -0600)]
Author: Alex Rousskov <rousskov@measurement-factory.com>
HTTP Compliance: delete Warnings that have warning-date different from Date.
Added HttpReply::removeStaleWarnings() method that iterates over all Warning
headers and removes stale warning-values. If a reply has no valid Date header,
all warning-values with warning-date are removed. Also, we remove
warning-value if we failed to parse warning-date.
removeStaleWarnings() is called from processReplyHeader(), after reply headers
are parsed.
Co-Advisor test cases:
test_case/rfc2616/date-accept-fmt-warn-asctime-rfc1123
test_case/rfc2616/date-accept-fmt-warn-asctime-rfc850
test_case/rfc2616/date-accept-fmt-warn-rfc1123-asctime
test_case/rfc2616/date-accept-fmt-warn-rfc1123-rfc850
test_case/rfc2616/date-accept-fmt-warn-rfc850-asctime
test_case/rfc2616/date-accept-fmt-warn-rfc850-rfc1123
Amos Jeffries [Fri, 8 Oct 2010 03:25:56 +0000 (21:25 -0600)]
Author: Henrik Nordstrom <henrik@henriknordstrom.net>
Bug 3056: comm.cc "!fd_table[fd].closing()" assertion from helperServerFree when a helper crashes while processing requests
reshuffle helperServerFree so it first unregisters the failed helper
and starts new ones if needed before it calls the callbacks on any
pending requests. If not those ends up resheduling the request on
this same crashed and partially shut down helper.
Author: Stefan Fritsch <sf@sfritsch.de>
Bug 3058: errorSend and ICY leak MemBuf object.
HttpReply::pack() returns a MemBuf pointer that must be deleted. Fixed leaking
errorSend() function in errorpage.cc and ICY parsing hack in
HttpStateData::processReplyHeader().
Bug 3053: cache version 1 LFS support detection broken
Alter the upgrade detection to only be used if needed, and to load the
correct on-disk sizes for the fields being converted.
Lock the sfileno type down to 32-bits.
This also adds two new upgrade parsers:
Fix 64-bit builds previously using sfileno as full 64-bit int
Migrates swap.state from 32-bit to 64-bit time_t (old squid 2.4/2.5)
64-bit->32-bit system time_t migration remains broken.
Per-file meta data is not altered by these changes, so problems may
remain there.
Author: Alex Rousskov <rousskov@measurement-factory.com>
Added expectNoConsumption() BodyPipe method to allow the consumer side to
tell the pipe that no more consumers are expected.
Calling expectNoConsumption() is needed when all consumers are gone but none
of them consumed anything. This is typical for HTTP server-side transactions
that abort before they receive the adapted ICAP request body. If FwdState
quits without calling expectNoConsumption(), the ICAP transaction supplying
the request body may get stuck waiting for buffer space. The body pipe may be
the ICAP only link with the master transaction once the header is handled.
This change is related to Squid bug #2964.
Based on lp 3p1-rock branch, r9609.
Author: Alex Rousskov <rousskov@measurement-factory.com>
Bug 2964: Prevent memory leaks when ICAP transactions fail.
We now make sure that heap-allocated objects are deleted if an exception
is thrown before the object pointers are saved/registered in a safe location
like a data member.
Assigning state.serviceWaiting=true after calling callWhenReady() in ModXact
prevents ModXact leak when callWhenReady() throws. This may need more work
to mark ModXact state appropriately for the adaptation log.
Based on lp 3p1-rock branch, r9610.
Added doneWithRetries() and used it to inform the request body sender that
there will be no more body consumers. This allows the sender (e.g., an ICAP
REQMOD transaction) to quit instead of waiting for body buffer space forever.
Moved !self check into checkRetry() because we need to call doneWithRetries()
even if self is nil. The move should not affect the old code.
Based on lp 3p1-rock branch, r9613.
At the end of preview, do not go into the writingPaused state if we already
received the final response from the ICAP server. Instead, stop writing so
that we do not get stuck waiting for the response that has already come.
May also handle header-only (zero-size) ieof Preview better.
TODO: Convert other HttpMsg pointer members to use safe HttpMsg::Pointer.
Author: Alex Rousskov <rousskov@measurement-factory.com>
Bug 2311: crashes with ICAP RESPMOD for HTTP body size greater than 100kb
BodyPipe::undoCheckOut() must not assert that undo is possible because it
is not (currently) possible if the pipe buffer was modified.
BodyPipe::undoCheckOut() must not throw if undo is not possible because it is
often called when there is already an exception thrown and because it is
called from the BodyPipeCheckout destructor and destructors should not throw
(this case is an illustration for one reason why they should not).
Currently, we only use an implicit undo, and only when an exception
is being thrown while the buffer is checked out.
Currently, the code that does checkout is probably safe because it should
terminate the transaction if a parser throws. However, this is not 100%
guaranteed, and the situation may change without us noticing.
TODO: consider implementing the long-term solution discussed at
http://www.mail-archive.com/squid-dev@squid-cache.org/msg07910.html
COW-buffers may help here as well
Prevent idnsVCClosed segfaults during shutdown or reconfiguration (at least).
idnsShutdown() schedules comm_close and then frees nameservers[] by
calling idnsFreeNameservers. The closing handler tried to access freed
nameservers[]. The patch prevents access to the freed nameservers[]
array in idnsVCClosed and other functions.
TODO: Nameservers[] array management should be rewritten. The array
should not be freed while there are nameservers using it. It should be
freed when the last entry is gone.
Author: Alex Rousskov <rousskov@measurement-factory.com>
HTTP/1.1: handle HTTP OPTIONS and TRACE requests with asterisk URIs.
Handle '*' URIs in urlParse(). This allows Squid properly respond to
OPTIONS and TRACE requests with '*' URIs and Max-Forwards value of
zero. Forwarding such requests is out of this change scope and still
does not work because the upstream host and port are not set.
Co-Advisor test cases:
test_case/rfc2616/options-bodyless-asterisk
test_case/rfc2616/maxForwardsZero-OPTIONS-asterisk
test_case/rfc2616/maxForwardsZero-TRACE-asterisk
An upgrade/fix to handling HTTP request-lines as specific by
section 5.1 of the RFCs. Specifically to handle a sequence of
unknown bytes up to a terminating LF (\n) octet.
* The semantics as previously documented are taken on. No changes
there, but documentation clarified a bit. Some things previously not
erroring are now doing so. External code impact is in the nature of
reduced special cases to be handled. Specifically raw-CR weirdness in
the request line fields. This occuring in URL was a vulnerability at
least once before.
* Prior updates to HttpParser object for other parse stages opens the
possibility of this parse action returning HTTP status code directly.
Additions are done to make use of this (with the existing status codes
only).
* Input permutations where the unit-tests showed the old parser was
violating its own documentation have been fixed to produce expected
outputs.
* Old parser operated three distinct potentially long parse loops.
Added several local variables to remember various octets seen while
searching for the terminal LF. This removed the need for two of the
parse re-scans (length of method, length of URI).
* relaxed_header_parser will enable it to also skip prefix whitespace
(space character only) and multiple-\r sequences at the end of line.
* --enable-http-violations is still required before it will accept
non-HTTP version types 'downgraded' to HTTP/0.9
Author: Alex Rousskov <rousskov@measurement-factory.com>
Added safe HttpMsg pointer wrapper that locks and unlocks the message.
This class will not be needed if we switch to refcounting HttpMsg. Meanwhile,
it allows to pass message pointers in AsyncCalls and avoid auto_ptr<> in
exception-sensitive code.
Author: Alex Rousskov <rousskov@measurement-factory.com>
Check for NULL and empty strings before calling str*cmp().
These checks are necessary to ensure consistent comparison results (important
for sorting and searching) and to avoid segfaults on NULL buffers (because
termedBuf() may return NULL instead of the expected "0-terminated buffer").
Amos Jeffries [Tue, 31 Aug 2010 01:43:31 +0000 (19:43 -0600)]
Author: Alex Rousskov <rousskov@measurement-factory.com>
Made eCAP compile again after CbcPointer<> changes.
Old eCAP code tried to call stillProducing(this) and stillConsuming(this)
methods from a const status() method. Doing so produces compiler errors
because stillProducing() and stillConsuming() do not accept pointers to
constant jobs.
CBDATA_CLASSes and, hence, CbcPointer<>, do not support const-correctness
well: In order to create/destroy a cbdata-based smart pointer, one has to
lock/unlock cbdata, which requires modifying the object. Thus, the smart
pointer cannot point to a truly constant object. The core of the problem is
that CBDATA_CLASSes keep cbdata and object data together. When all raw/dumb
CBDATA_CLASS pointers are gone, we can separate the two "datas" and solve the
const-correctness problem for good. The "separate-datas" design would even be
consistent with the original cbdata design which we often violate, IMO.
There are other workarounds. We could declare toCbdata() constant, for
example. However, that would essentially disable checks where a
cbdata-protected object is being destroyed despite the caller's intent to keep
the object constant. This change is not as general but is also much less
intrusive.
Amos Jeffries [Sun, 29 Aug 2010 00:52:30 +0000 (18:52 -0600)]
Author: Stefan Fritsch <sf@sfritsch.de>
Bug 2872: leaking file descriptors
As I understand it, the leak happens this way: A client request kicks off an
asynchronous file open request. If the client request is aborted and disappears
before the file open has completed, the file is never closed again. This
explains why this leak can only happen with aufs and not with ufs.
Amos Jeffries [Sun, 29 Aug 2010 00:49:56 +0000 (18:49 -0600)]
Author: Henrik Nordstrom <henrik@henriknordstrom.net>
Harden DNS client against packet queue attacks.
Strengthen the internal DNS client somewhat by making sure to keep
the receive queue drained. Also avoid parsing messages unless we
have a pending query.
Amos Jeffries [Fri, 27 Aug 2010 16:46:02 +0000 (10:46 -0600)]
Author: Alex Rousskov <rousskov@measurement-factory.com>
HTTP Compliance: remove Content-Length header if Transfer-Encoding is present.
If after HTTP header parsing we have both "Transfer-Encoding: chunked"
and Content-Length headers, remove the Content-Length entry. The
adjusted behavior follows httpbis recommendations (ticket #95, part 2).
The old client-side code forwarded the original Content-Length header
which did not match the [dechunked] response, resulting in a malformed
response.
HttpHeader::chunked() method added to check if HTTP headers contain
chunked Transfer-Encoding header. Use this method in code that checks
for chunked encoding.
Co-Advisor test cases: test_case/rfc2616/chunked-1p0-badClen-toClt
test_case/rfc2616/chunked-1p1-badClen-toClt
Amos Jeffries [Fri, 27 Aug 2010 16:45:08 +0000 (10:45 -0600)]
Author: Alex Rousskov <rousskov@measurement-factory.com>
HTTP/1.1: respond to OPTIONS requests with a zero Max-Forwards value.
RFC 2616 section 9.2 says that a proxy MUST NOT forward requests with a
zero Max-Forwards value. RFC 2616 does not define any proper OPTIONS
responses, so we consider successful responses optional and reply with
501 Not Implemented.
No change in handling OPTIONS requests with positive Max-Forwards values.
While TRACE and OPTIONS are similar with regard to Max-Forwards, we
handle them in different places because OPTIONS responses do not need to
echo the request via Store.
Co-Advisor test case: test_case/rfc2616/maxForwardsZero-OPTIONS-absolute
Amos Jeffries [Fri, 27 Aug 2010 16:41:32 +0000 (10:41 -0600)]
Author: Alex Rousskov <rousskov@measurement-factory.com>
HTTP/1.1: Send chunked responses if body size is unknown.
Apply HTTP chunked transfer encoding to the response body sent to client
if all of the following conditions are met:
* client claims HTTP version 1.1 or later support
* response does not have a Content-Length header already
* response does not use multipart/byteranges encoding
* connection is persistent
If we decide to send chunked reply, chunked_reply flag is set. Chunked
encoding is done in ClientSocketContext::packChunk(). The last-chunk
is sent only when clientReplyContext complete flag is set.
This change helps keep client-side connections persistent.
Amos Jeffries [Fri, 27 Aug 2010 16:16:29 +0000 (10:16 -0600)]
Author: Alex Rousskov <rousskov@measurement-factory.com>
Bug 2583: pure virtual method called
When a cbdata-protected class holds its own cbdata and has virtual
toCbdata(), there is a catch22 problem: we need cbdata to know whether
the pointer to the class object is valid, and we need to dereference
that pointer to get cbdata.
Added CbcPointer class to hold both a pointer to a potentially freed
class object and the cbdata pointer protecting that object. Keeping the
cbdata pointer allows us to test whether the object is still there
without dereferencing the object pointer.
Use the CbcPointer class to hold safe pointers to AsyncJobs. This
prevents "pure virtual method called" failures because we no longer
dereference freed job pointers.
Removed Initiator parameter from many initiatee constructors. The
Adaptation::Initiator::initiateAdaptation method now sets the initiator
of the job. This makes the constructor profile simpler and removes the
need to propagate Initiator changes through all the [nested]
constructors.
Renamed AsyncJob::AsyncStart() to AsyncJob::Start(). I had to change the
callers code anyway and it was a good opportunity to remove the
redundant "Async".
Special thanks to Stefan Fritsch for updating and testing an earlier
version of this patch.
With the change to correct HTTP/1.1 keep-alive behaviour it has become
apparent that the major browsers fail to handle NTLM re-challenge cleanly
over persistent connections.
This alters the default behaviour for NTLM and Negotiate auth when not
explicitly configured. It causes connections to break during initial
protocol negotiation, which while not desirable was the original HTTP/1.0
behaviour of Squid 3.1 on which the browsers appear to depend.
Installs which have explicitly set their keep_alive parameters to ON, may
need to re-asses.
Amos Jeffries [Thu, 19 Aug 2010 02:27:34 +0000 (20:27 -0600)]
Author: Alex Rousskov <rousskov@measurement-factory.com>
Bug 3016: HTTP/1.1 compliance: default keep-alive for 1.0/1.1 clients.
aka. NTLM Authentication with Java UA + SSL Problem
Moved httpMsgIsPersistent(version, headers) to HttpMsg::persistent(void).
This move makes it clear that the logic applies only to the message being
examined and not some irrelevant information such as HTTP version supported
by Squid.
Side-effects:
* Squid starts using persistent connections with HTTP/1.1 clients
that do not send "Connection: close".
Amos Jeffries [Wed, 18 Aug 2010 01:46:52 +0000 (19:46 -0600)]
Fix 32-bit wrap in refresh_pattern min/max values.
Attached patch limits the values to 1 year (arbitrary based on rumours
about good caching times). Checking for 32-bit wrap and setting the max
1 year limit instead of cutting them to zero.
The expected outcome of this is correct cache storage time extension
according to refresh_pattern documentation when people desperately set
min/max to > a million minutes. Instead of a silent always-stale verdict.
Amos Jeffries [Wed, 18 Aug 2010 01:45:20 +0000 (19:45 -0600)]
HTTP/1.1 compliance: Stop using Proxy-Connection header
The Proxy-Connection header is not part of any HTTP standard. It was added
by Netscape to differentiate persistent connections to intermediary proxies
but that duty has been formally superceded by the Connection: header.
This compliance update makes Squid stop sending Proxy-Connection on outbound
requests. Starts consistently using Connection: header instead.
The Proxy-Connection header is also ignored on HTTP-strict builds.
For compatibility we must do a small violation and drop it as a hop-by-hop
header despite strict-mode technically being required to pass it through.
For origin server connections the non-strict builds will retain the
status-quo: interpret it, but treat it as an HTTP/0.9 thing to be
upgraded to HTTP/1.1 Connection: header.
Amos Jeffries [Wed, 18 Aug 2010 01:38:05 +0000 (19:38 -0600)]
Author: Christos Tsantilas <chtsanti@users.sourceforge.net>
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.
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.
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
Amos Jeffries [Tue, 10 Aug 2010 07:53:05 +0000 (01:53 -0600)]
Author: Alex Rousskov <rousskov@measurement-factory.com>
HTTP/1.1 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 13:34:08 +0000 (07:34 -0600)]
Hack: define top_build_prefix for old autotools
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.
projects / thirdparty / squid.git / log
