Re: Cache control in trailers?

------ Original Message ------
From: "Roy T. Fielding" <fielding@gbiv.com>

>Personally, I think end-status is the easiest and most reusable solution, for
>any number of features that might need to know if something broke. However,
>Willy is right that saying must-revalidate up front and then softening that
>at the end would be the safer choice where completion is more important
>than default performance. I suggest that choice needs to be resource-specific.
>
>
The "Something broke" could also apply to a scanning intermediary.  E.g. 
some message body was found to contain a virus.

If an intermediary could signal that the final status may be different, 
and rely on clients to obey that, then it could safely stream unscanned 
data to the client, and indicate the result at the end, knowing the 
client will discard the message body.

This would avoid all manner of hacks which don't work very well but are 
required to stop client agents from e.g. timing out due to lack of data 
(as intermediary spools and scans).

It might be necessary if defining a new field which indicates a final 
result, to indicate to authors that it might be a good idea not to 
render a message body until the final status is received (to avoid 
susceptibility to exploits).

Adrien



>

Received on Friday, 5 February 2021 21:13:05 UTC