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
I noticed that the header.Set function seems to have a problem when handling cookies. According to the definition of Set, it seems that when operating cookies, all current cookies should be cleared and then new values should be added. However, when the following code actually performs the operation, the original cookies are still retained, making the actual effect become adding cookies:
May I ask if I have misunderstood the meaning of the operation, and this effect is actually expected by fasthttp? Or is there indeed some problem? If there is indeed a problem, I am happy to submit a pull request to fix it.
Best wishes!
The text was updated successfully, but these errors were encountered:
Yes, among all special headers, Cookie is indeed unique in that it is the only one that allows multiple values and should be considered separately. Although there is a Header.SetCookie method that performs similar behavior, it is specifically designed for the Cookie header. Even if the semantics are slightly incorrect, it can be justified as long as documentation is provided to explain it.
Given that Request.Header includes Add and Set methods, which were designed with precise semantics in mind, addressing the issue would ensure consistency and accuracy in handling multi-value headers.
I think this has almost no backward compatibility issues.
I personally support your submission of this pull request.
Hello developers,
I noticed that the header.Set function seems to have a problem when handling cookies. According to the definition of Set, it seems that when operating cookies, all current cookies should be cleared and then new values should be added. However, when the following code actually performs the operation, the original cookies are still retained, making the actual effect become adding cookies:
fasthttp/header.go
Lines 1474 to 1477 in 65e989e
fasthttp/cookie.go
Lines 505 to 516 in 65e989e
This also caused a downstream issue.
May I ask if I have misunderstood the meaning of the operation, and this effect is actually expected by fasthttp? Or is there indeed some problem? If there is indeed a problem, I am happy to submit a pull request to fix it.
Best wishes!
The text was updated successfully, but these errors were encountered: