To that end. Could the actual flags be fully documented in a "TO-DO" file explaining what each one does. If this is applicable to file level only then it's easily extended to xroot protocol. At the moment no one (other than JT) is asking for this kind of functionality and when it is asked it's in the context of HTTP. I also agree that we don't want to start changing everthing to provide 100% consistency in terms of cache control. From what I understand, these flags are considered "best effort" and might be ignored if they cannot be fullfilled even in the HTTP world world. In the end, it all winds up being a compromise. On Tue, 14 Mar 2023, Brian P Bockelman wrote: >> Or you were only thinking of using http? > > I would like the feature to be generally useful for any protocol. However, since the driver is better HTTP 1.1 compliance, unless there's a need to push the functionality all the way through to the reads themselves, it seems simpler to leave it as a file-level property. I can see some downsides around code complexity in the read path. > > -- > Reply to this email directly or view it on GitHub: > https://github.com/xrootd/xrootd/pull/1954#issuecomment-1468020991 > You are receiving this because your review was requested. > > Message ID: ***@***.***> -- Reply to this email directly or view it on GitHub: https://github.com/xrootd/xrootd/pull/1954#issuecomment-1468255847 You are receiving this because you are subscribed to this thread. Message ID: <[log in to unmask]> ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the XROOTD-DEV list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1