Hi -
> > > > That in turn would require THREE new API functions or a
> > > > stateful set_HEAD_mode_and_return_dev_null one and modifying
> > > > the three main lookup functions.
> > > Yes, it definitely is more work.
> >
> > So, is that your suggestion? We proceed with that sort of thing?
>
> Yes, separate the verbose printing of http headers (which I really do
> like)
(This is now done, more or less, but noting that it is not a
machine-consumable API.)
> from providing an interface to query what needs to be done to get
> some file (is it in cache, can it be retieved from a remote server, how
> big is it?) I don't think providing raw http headers is that interface.
Well, we have gone some way into this on PR28284, on various branches
including nsanci/pr28284-webapi. It's not complete, yet the "raw http
headers" aspect is still there, because what headers are available is
unpredictable. But now this is made even more wordy by forking the
_find_ functions into a _describe_ triplet and all the other leftover
work elsewhere.
IMHO it's not an improvement over a single function that returns
headers associated with the lookup. Please let's discuss this again.
- FChE
