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
but curl ignores set-cookies from response (response have set-cookies, I check it through Wireshark). How can I overcome this behaviour?
cookie.sub:
# Netscape HTTP Cookie File
# https://curl.se/docs/http-cookies.html
# This file was generated by libcurl! Edit at your own risk.
#HttpOnly_::1 FALSE /notifications/ FALSE 0 <manual set cookie name> <cookie value>
# Netscape HTTP Cookie File
# https://curl.se/docs/http-cookies.html
# This file was generated by libcurl! Edit at your own risk.
#HttpOnly_::1 FALSE /notifications FALSE 0 name0 value0
curl:
➜ curl_cookie curl -vvv -b cookie.txt -c cookie.txt '[::1]:1025/notifications'
* Trying [::1]:1025...
* Connected to ::1 (::1) port 1025 (#0)
> GET /notifications HTTP/1.1
> Host: [::1]:1025
> User-Agent: curl/7.86.0
> Accept: */*
> Cookie: name0=value0
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Set-Cookie: name1=Value1; Path=/notifications; HttpOnly; Secure
< Date: Tue, 20 Dec 2022 08:37:36 GMT
< Content-Length: 13
< Content-Type: text/plain; charset=utf-8
<
Hello World!
* Connection #0 to host ::1 left intac
http.go:
➜ curl_cookie go run ./http.go
:1025
Got cookies: `[name0=value0]`
And cookie.txt doesn't change.
I also upgrade curl:
The bug is that curl checks for the host name [::1] while it is stored as ::1 and therefore wrongly does not consider it to be a "secure context". Tentative fix in #10121
Activity
http: fix the ::1 comparison for IPv6 localhost for cookies
BratSinot commentedon Dec 20, 2022
wireshark.pcapng.txt
Also here is minimal reproducible example:
http.go:
cookie.txt:
curl:
http.go:
And cookie.txt doesn't change.
I also upgrade curl:
I've also checked it in
golang:1.19.4-bullseyedocker container (to get rid of possibility what it MacOS doing something wrong), still no cookies.bagder commentedon Dec 20, 2022
The bug is that curl checks for the host name
[::1]while it is stored as::1and therefore wrongly does not consider it to be a "secure context". Tentative fix in #10121