Re: Push caching with squid

Hi Squid-lovers,

We at A&T Systems have proposed and implemented a PUSH method based on
Squid for Web caching. This is one of the components in the Internet
Delivery System (IDS) being developed for Intelsat with the assistance from
the Network
Research Group at the computer science department of Virginia Tech. IDS will
be demonstrated in the Internet Summit in Washington DC this coming November.

General:
The proposed PUSH method inserts HTTP objects received from multicast or
other sources into a particular cache storage along a proxy chain. A cache
server supporting the PUSH method will allow a client application to
register and store
an HTTP object into its cache storage directly, fast and efficiently.

The following diagram shows the added functionality from a PUSH method in a
proxy chain:
            PULL PULL
Web_Client --> ...PROXYi ... --> Web_Server
                       ^
                      | PUSH
                        
where Web_Client can be a browser; Web_Server is the origin server. Proxies
are cache servers in between. The PUSH arrow shows where the push contents
come from.

Method Definition:
The PUSH method is similar to other conventional methods defined in HTTP
1.1, the PUT method in particular. It should comply with the specification
for proxies as defined in RFC2068. The PUSH method reuses the the protocol
parameters and follows the same message format as defined in HTTP1.1.

First of all, a PUSH method has an associated ACL (access control list)
which defines the authorized Web clients list. These clients can be
identified by their IP addresses. A PUSH request is checked against such
ACL before it is accepted
and processed.

A PUSH method requests that the enclosed entity be stored under the
supplied Request-URI into the cache storage. If the Request-URI refers to
an already existing entry in the cache, the enclosed entity can be always
considered as an updated version of the one residing on the cache, or can
be compared with the existing object to retain the fresher copy only. If
the Request-URI does not point to an existing entry in the cache, and that
URI is cachable, the cache server
should create a new entry and store the object. If a new entry is created,
the cache must return the HTTP response with code 201 (created); if the
entry already exists, the cache must return the HTTP response with code 200
(OK). A failure is signaled by a HTTP reponse with code 400 (Bad request).

Data Flow:
The data flow will have two cases depending on if the Content-length is in the
request header. If the Content-length is unknown, the end indication is a
Close
from the Client, and the Client can not receive the confirmation reply from
the
proxy.

Case 1:
Client Proxy Cache
PUSH URL HTTP/version <crlf>
[Request Header]
Content-length: xxxx
---------------------------------------------->100 Continue
<---------------------------------------------
[Entity Body]
---------------------------------------------->200 Ok
<---------------------------------------------
Close or Pipeline next request

Case 2:
Client Proxy Cache
PUSH URL HTTP/version <crlf>
[Request Header]
---------------------------------------------->100 Continue
<---------------------------------------------
[Entity Body]
Close

The fundamental difference between the PUSH and POST or PUT requests is
that, PUSH
will affect only the cache proxy the PUSH is sent to. A PUSH request will
never be
forwarded to another cache proxy like a POST or PUT request. Contents
disemination is driven by other mechanisms such as ICP.

Message Format:
PUSH request and response shall obey the message transmission requirements
set out in HTTP 1.1. Therefore, the request syntax is:

|------PUSH REQUEST -----------------------------------------|
PUSH URL HTTP/version <crlf>
[Request Header]

[Entity body]
|------------------------------------------------------------|

where the entity holds the HTTP object, which is a Reply Header plus an
HTML page.

The PUSH reply syntax is:

|------PUSH REPLY--------------------------------------------|
HTTP/version Status_Code Explanation <crlf>
[Reply Header]

|------------------------------------------------------------|

There is no reply body in the PUSH reply.

Examples:
A PUSH request example:

|------A PUSH REQUEST----------------------------------------|
PUSH http://www.foo.com/page.html HTTP/1.0
Content-length: 4090

HTTP/1.0 200 OK
Content-type: text/html
Content-length: 4061

<HTML>
….
….
….
</HTML>
|------------------------------------------------------------|

A PUSH response example:

|------A PUSH REPLY------------------------------------------|
HTTP/1.0 200 OK

|------------------------------------------------------------|

Implementation:
The project is undergoing at A&T system. The implementation details and
modifications of Squid will be presented later. For further information,
please contact with developers:
tjohnson@csgrad.cs.vt.edu or pchen@ats.com

H. Phillip Chen,
Manager of Cache and Multicast Development, IDS
A&T Systems
Silver Spring, MD 20904
Received on Wed Sep 02 1998 - 10:30:48 MDT