Re: Pragma header in 304 res

I did not read your message as a complaint.

These discussions are needed, and you are most welcome to continue
asking strange questions related to HTTP compliance or other similar
things.

You did uncover a bug in that Squid never forwards the modified headers.
It is supposed to for at least the duration the memory object stays in
memory. However, persistent updates of the on-disk objects are not yet
implemented at all, and would not happen even if the memobject headers
was used correctly...

/Henrik

Hirohiko Nakano wrote:
>
> Henrik and Alex. Thank you for you kind responses.
>
> I am sorry for posting troublesome emails about "Pragma in 304" and "Authentication-Info in 304".
> My intention is NOT to complain to squid's developers.
> I posted the following mail to squidML in 8/18,
> because somebody else may be in trouble about the same problem,
> especially somebody who want to use/implement DA auth.
>
> But no response from users...
>
> Now I am using squid (with modification) for my research.
> Open source is great!!
>
> Thank you.
>
> Hirohiko Nakano wrote (in 8/18, a month ago):
> >
> >I use Squid 2.3 Stable 3 on RetHat Linux 6.2.
> >Now, I am planning to design and implement another Http auth scheme, which needs sending auth-info
> >from server to client. I decide to use Pragma: header to transfer auth-info to client
> >(because Authentication-Info: header is not supported by Squid yet).
> >
> >Squid supports "public", "max-age" and "must-revalidate" cache-control directives,
> >so I use these directives to cache authorized response. I am very happy.
> >But, when I (= server) send to 304 response to squid with Pragma: header(including auth-info),
> >Squid sends old (cached) Pragma: header to client! My authentication sheme does not work!
> >
> >I refer to RFC of HTTP/1.1.
> >RFC 2616 (Latest HTTP/1.1 RFC) says:
> >
> >13.5.3 Combining Headers
> >
> > When a cache makes a validating request to a server, and the server
> > provides a 304 (Not Modified) response or a 206 (Partial Content)
> > response, the cache then constructs a response to send to the
> > requesting client.
> >
> > If the status code is 304 (Not Modified), the cache uses the entity-
> > body stored in the cache entry as the entity-body of this outgoing
> > response.
> >
> > The end-to-end headers stored in the cache entry are used for the
> > constructed response, except that
> >
> > - any end-to-end headers provided in the 304 or 206 response MUST
> > replace the corresponding headers from the cache entry.
> >
> >
> >I think that Squid does not obey this rule.
> >
> >I browse Squid src, then I add the following code to "clientBuildReplyHeader()" in client_side.c:
> >
> > /* Append X-Cache */
> > .....
> > if(is_hit) {
> > if(httpHeaderHas(&(http->entry->mem_obj->reply->header), HDR_PRAGMA))
> > {
> > String s;
> > s = httpHeaderGetList(&(http->entry->mem_obj->reply->header),
> > HDR_PRAGMA);
> > httpHeaderDelById(hdr, HDR_PRAGMA);
> > if(strLen(s)) httpHeaderPutStr(hdr, HDR_PRAGMA, strBuf(s));
> > }
> > }
> > .....
> >
> >This modification is not perfect, but suitable for my purpose.
> >My modification is legal to HTTP/1.1 protocol?
> >How about this problem?
> >
>
> ----
> Hirohiko Nakano nakano@hp-info.med.osaka-u.ac.jp

--
To unsubscribe, see http://www.squid-cache.org/mailing-lists.html