You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In current implementation (0.2.1), after you set a combined field value via the plain subscript method, you will get the combined value from raw subscript method too:
I'll let the maintainers speak to the direction of this behavior but I can tell you what is going on here at least;
When setting:
fields[.acceptLanguage]="en-US, zh-Hans-CN"
And then accessing it via fields[.acceptLanguage] you are expected to get an optional string back based on the subscript definition for the HTTPField.Name usage:
public subscript(name:HTTPField.Name)-> String?{...}
And likewise, an array of strings when using the [raw: ]` accessor:
public subscript(raw name:HTTPField.Name)->[String]{
Note that the HTTPField.Name accessor calls into the [raw: ] accessor to build the string return value.
But having the [raw: ] accessor could be handy in cases where there are multiple values that you'd want to easily enumerate over as opposed to splitting strings by a comma.
The string subscript sets a single header field. It does not do anything smart like splitting the header field by comma since it's not always safe to do so (Set-Cookie and WWW-Authenticate for example). The consequence is that sometimes fields[name] = fields[name] would modify the fields (which is unavoidable since this convenience subscript can't preserve the boundary between fields).
raw gives you the list of values as an array. If you do fields[raw: name] = ["a, b", "c"], fields[raw: name] will return ["a, b", "c"]. fields[name] = "a, b, c" is equivalent to fields[raw: name] = ["a, b, c"].
In current implementation (0.2.1), after you set a combined field value via the plain subscript method, you will get the combined value from raw subscript method too:
But I expect the raw subscript method will return
["en-US", "zh-Hans-CN"]
in the above example. Is current behavior expected? Or it is a bug?The text was updated successfully, but these errors were encountered: