On Tue, Sep 08, 2020 at 04:11:40PM +0200, Tim Düsterhus wrote:
> William,
>
> [Did you leave out the list intentionally?]
>
Oops, no sorry, I'll bounce my previous mail on the list.
> Am 08.09.20 um 14:40 schrieb William Lallemand:
> >> diff --git a/include/haproxy/applet-t.h b/include/haproxy/applet-t.h
> >> index 60f30c56f..7cccec977 100644
> >> --- a/include/haproxy/applet-t.h
> >> +++ b/include/haproxy/applet-t.h
> >> @@ -113,6 +113,7 @@ struct appctx {
> >> unsigned int offset; /* start offset of
> >> remaining data relative to beginning of the next block */
> >> unsigned int rem_data; /* Remaining bytes for the
> >> last data block (HTX only, 0 means process next block) */
> >> struct shared_block *next; /* The next block of data
> >> to be sent for this cache entry. */
> >> + struct ist if_none_match; /* The if-none-match
> >> request header. */
> >> } cache;
> >
> > In my opinion we only need a flag here, because the validation must be
> > done near the lookup. It's not useful to do a copy of the header string.
>
> Yes, this generally makes sense to me. Unfortunately the code frankly
> is a foreign language to me here.
>
> I have not the slightest idea what steps I would need to perform to get
> the headers of the cached response within 'http_action_req_cache_use'.
> That's the primary reason why I implemented the logic within
> 'http_cache_io_handler' and not in 'http_action_req_cache_use'.
Indeed it's kind of complicated in the current state of the cache,
because the data are chunked in the shctx so you can't use the htx
functions to do it, so we need to dump the headers before.
> I would also say that doing this in 'http_cache_io_handler' is
> logically the correct place, because we are already dealing with the
> response here. However I understand that needing to malloc() the
> if-none-match is non-ideal.
>
> Do you have any advice how I can efficiently retrieve the ETag header
> from the cached response in 'http_action_req_cache_use'?
I think it's better to handle the headers in the action, like it's done
for the store_cache where the action store the headers and the filters
stores the body.
So what could be done is to dump the headers directly from the action,
so the applet is created only in the case there is a body to dump, that
could even improve the performances.
It will be a requirement in the future if we want to handle properly the
Vary header because we will need to chose the right object depending on
the header before setuping the appctx.
Also, when reading the RFC about the 304, I notice that they impose to
remove some of the entity headers in the case of the weak etag, so the
output is not exactly the same as the HEAD.
https://tools.ietf.org/html/rfc2616#section-10.3.5
Regards,
--
William Lallemand
