多くのWebアプリは、複数のSet-Cookieヘッダー(1つのCookieに対して1つのヘッダー)でCookieを送信します。 リクエストは、このヘッダーをコンマで区切られた1つの大きなヘッダーに結合します。
同じWebアプリからrequests.getへ
Set-Cookie: ASP.NET_SessionId=token1; path=/; HttpOnly
Set-Cookie: Cookie1=token2; path=/ecp
Set-Cookie: X-BEResource=WIN-RBFR0BDA7V7.testlab.net~1; path=/ecp/15.0.516.30; HttpOnly
Set-Cookie: X-BackEndCookie=token3; expires=Mon, 03-Apr-2017 12:25:07 GMT; path=/ecp; HttpOnly
リクエストの場合:
resp.headersこれは次のようになります
Set-Cookie: ASP.NET_SessionId=token1; path=/; HttpOnly,
Cookie1=token2; path=/ecp,
X-BEResource=WIN-RBFR0BDA7V7.testlab.net~1; path=/ecp/15.0.516.30; HttpOnly,
X-BackEndCookie=token3; expires=Thu, 06-Apr-2017 08:27:22 GMT; path=/ecp; HttpOnly
Firefox、IE、Chromeは、区切り文字がコンマであるため、このCookieを無効に解釈しましたが、フィールドEXPIRESコンマで日付と日付を区切ります。
変更トラフィックの主な問題。 私の意見では、サーバーは複数のヘッダーを送信しますlibは複数のヘッダーを返す必要があります
リクエストは、サーバーから受信した形式でヘッダーを残すことを約束しません。 現時点では、ヘッダーからCookieを抽出するのではなく、RequestsがCookieを保存するために使用するcookiejarを使用することを強くお勧めします。Cookieはそこに正しく挿入されます。
長期的には、 Set-Cookie
ヘッダーをこの方法で結合しないように修正を追加する必要があります。
これは私たちを噛み、かなりの時間の費用がかかりました。 Set-Cookie
そのままにしておくことに投票したいと思います。 とにかくリクエストがヘッダーをいじるのはなぜですか? それにはいくつかの正当な理由がありますか? 私見それは皆のために物事を複雑にするだけです。 何が足りないのですか?
お疲れ様でした!
こんにちは。https://github.com/Ousret/kiss-headersを使用してヘッダーを正しく解析する方法がありrequests
は、ヘッダーの表現をすぐに変更できなくなります。
最も参考になるコメント
リクエストは、サーバーから受信した形式でヘッダーを残すことを約束しません。 現時点では、ヘッダーからCookieを抽出するのではなく、RequestsがCookieを保存するために使用するcookiejarを使用することを強くお勧めします。Cookieはそこに正しく挿入されます。
長期的には、
Set-Cookie
ヘッダーをこの方法で結合しないように修正を追加する必要があります。