Description
Our current ConsiderationsForServiceDesign includes this statement in the PUT with additional long-running processing section:
If the resource supports ETags, the response may contain an etag header and possibly an etag property in the resource.
However, @johanste pointed out in a review comment on PR #517
Per RFC9110:
An origin server MUST NOT send a validator field (Section 8.8), such as an ETag or Last-Modified field, in a successful response to PUT unless the request's representation data was saved without any transformation applied to the content
Since the status property is readOnly, I don't see any situation where the service would be allowed to send an etag header.
If we choose to follow this aspect of the HTTP RFC, I think eTags would have to be eliminated from the vast majority of PUT responses in Azure -- not just LRO puts. Any resource with a readOnly field would be barred from returning an eTag from PUT.