Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Avoid RFC6919 terminology :) #142

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Avoid RFC6919 terminology :) #142

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions http-warning/draft-cedik-http-warning-03.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -88,7 +88,7 @@ Content-Warning = sh-list
</list>
</t>
<t>
Intermediaries of a response are not allowed to modify existing Content-Warning fields, but can add additional entries if warnings are produced while they are handling a response.
Intermediaries of a response MUST NOT modify existing Content-Warning fields, but they MAY add additional entries if warnings are produced while they are handling a response.
</t>
<section anchor="http-request-methods" title="HTTP request methods">
<t>
Expand Down Expand Up @@ -250,7 +250,7 @@ Content-Warning: "embedded-warning"; 1590190500
API providers need to exercise care when reporting warnings. Malicious actors could use this information for orchestrating attacks. Social engineering can also be a factor when warning information is returned by the API.
</t>
<t>
Clients processing warning information SHOULD make sure the right type of content was transmitted by checking the content-type header as well as the content-warning field. Content in the bodys warnings object SHOULD be processed accordingly. If no content-warning field was provided, clients are advised to ignore the content provided in the bodys warnings object.
Clients processing warning information SHOULD make sure the right type of content was transmitted by checking the content-type header as well as the content-warning field. Content in the body of the warnings object SHOULD be processed accordingly. If no content-warning field was provided, clients are advised to ignore the content provided in the body of the warnings object.
</t>
<section anchor="absence-of-a-response-body" title="Absence of a response body">
<t>
Expand Down