httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoffrey Young <>
Subject Re: new ETag supression/weakening API
Date Fri, 12 Dec 2003 19:10:57 GMT

Paul J. Reder wrote:
> I just have a quick comment based on some work I did recently.
> You should check for the ETag value in both headers_out locations.
> It is actually a bit more likely that the ETag will be in
> r->err_headers_out
> rather than r->headers_out, but it could be in either. 

hmm, I had thought about that.  ap_meets_conditions only checks headers_out,
so I figured it was safe.

but you bring up an interesting point.  outside of this patch, if somebody
manually populates an ETag header in err_headers_out then it won't be caught
by the "no-etag" stuff we already depend on.  I'll account for that as well.

> Your patch should
> look in both locations and stick the altered value back where you found it.

yes, good idea.  and it brings up another good point.  the weaken API only
worked for tags generated with ap_make_etag - manual ETag entries could pass
through to the client unaltered if they happen after the new ap_weaken_etag
call.  so, some additional logic is required in the header filter to take
care of those cases.

> The other comment I have is that in the ap_weaken_etag function you call
> etag = apr_table_get(r->headers_out, "ETag") twice (once in the decl/init
> and once in the conditional).

drat.  refactoring leakage :)

> Other than that, I'm not enough of an expert on tags and weakness...
> from what
> I do know this looks good, but some doc for the function might be useful to
> help folks know when they might be legally able to weaken a tag.

sure.  I placed a brief bit and a pointer to the docs in httpd.h, in
addition to expanding the comments in the weaken function more.  is there
someplace else that's appropriate?

thanks for your input - new patch attached.


View raw message