-
Notifications
You must be signed in to change notification settings - Fork 9.1k
v3.2: Provide guidance for the Set-Cookie
response header
#4748
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.
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
base: v3.2-dev
Are you sure you want to change the base?
Conversation
The Set-Cookie response header breaks the normal rules for headers with multiple values and requires special handling.
Co-authored-by: Phil Sturgeon <[email protected]>
With apologies to @philsturgeon for clearing his approval (its' set to automatically do that if anything changes) I realized we don't need |
Also remove a stray line from an example that didn't really hurt but wasn't needed and could have been confusing.
OK apparently I was more out-of-it yesterday with this cold than I thought. Now I have added the commit that does things I mentioned in the last comment! 🤦 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm mostly in favour, with some minor editorial comments. Do we need to wait for the dataValue/serializedValue elements to resolve though? I see them in an example here.
|
||
RFC9110 therefore advises recipients to 'handle "Set-Cookie" as a special case while processing fields,' so the OAS similarly special-cases its handling of `Set-Cookie`. | ||
|
||
When an OAS implementation is mapping directly between the multi-`Set-Cookie:` header line format and an array representation, without any intermediate single string holding the multiple values, no special handling is needed as the behavior is the same as for headers that can be either on a single line with comma-separated values or on multiple lines. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This wasn't instantly clear to me. Multi-header? Multi-line? I think we want to explain that we're mapping between the format of multiple set-cookie headers and an array representation but I may have confused myself by now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lornajane yeah this is a bit weird and I could use some help streamlining it. It might take a bit before I can come back and explain because I want to update PR #4673 to be more clear, which I think will help explain this. Or at least help me sort out my thoughts.
Co-authored-by: Lorna Jane Mitchell <[email protected]>
Partially addresses issue #1237
The Set-Cookie response header breaks the normal rules for headers with multiple values and requires special handling.
There are two options here:
Set-Cookie
in a consistent mannerSet-Cookie
as a special case and define how it relates to normal behaviorSince RFC9110 §5.3 advises clients to treat
Set-Cookie
as a special case, I went with special-casing it. This assumes the approach to header serialization that is described in PR #4648 and discussed in one of its comment threads (specifically, that it does not include the header name which is required for it to be consistent with howstyle: "simple"
andexplode
are treated elsewhere and are defined in RFC6570).