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
