2016-12-24 4 views
2

Ich verwende Hyper, um HTTP-Anfragen zu senden, aber wenn mehrere Cookies in der Antwort enthalten sind, kombiniert Hyper sie zu einer, die dann die Analyseprozedur fehlschlägt.Wie behandelt man mehrere Set-Cookie-Header in Hyper korrekt?

Zum Beispiel, hier ist ein einfacher PHP-Skript

<?php 

setcookie("hello", "world"); 
setcookie("foo", "bar"); 

Antwort mit curl:

$ curl -sLD - http://local.example.com/test.php 
HTTP/1.1 200 OK 
Date: Sat, 24 Dec 2016 09:24:04 GMT 
Server: Apache/2.4.25 (Unix) PHP/7.0.14 
X-Powered-By: PHP/7.0.14 
Set-Cookie: hello=world 
Set-Cookie: foo=bar 
Content-Length: 0 
Content-Type: text/html; charset=UTF-8 

jedoch für den folgende Rust Code:

let client = Client::new(); 
let response = client.get("http://local.example.com/test.php") 
    .send() 
    .unwrap(); 
println!("{:?}", response); 
for header in response.headers.iter() { 
    println!("{}: {}", header.name(), header.value_string()); 
} 

... der Ausgang be:

Response { status: Ok, headers: Headers { Date: Sat, 24 Dec 2016 09:31:54 GMT, Server: Apache/2.4.25 (Unix) PHP/7.0.14, X-Powered-By: PHP/7.0.14, Set-Cookie: hello=worldfoo=bar, Content-Length: 0, Content-Type: text/html; charset=UTF-8, }, version: Http11, url: "http://local.example.com/test.php", status_raw: RawStatus(200, "OK"), message: Http11Message { is_proxied: false, method: None, stream: Wrapper { obj: Some(Reading(SizedReader(remaining=0))) } } } 
Date: Sat, 24 Dec 2016 09:31:54 GMT 
Server: Apache/2.4.25 (Unix) PHP/7.0.14 
X-Powered-By: PHP/7.0.14 
Set-Cookie: hello=worldfoo=bar 
Content-Length: 0 
Content-Type: text/html; charset=UTF-8 

Das scheint mir wirklich komisch zu sein. Ich benutzte Wireshark, um die Antwort zu erfassen, und es gibt zweiSet-Cookie Header darin. Ich habe auch die Hyper-Dokumentation überprüft, aber keine Ahnung ...

Ich bemerkte, dass Hyper intern verwendet VecMap<HeaderName, Item>, um die Header zu speichern. Also verketten sie die zu einem? Wie soll ich sie danach in einzelne Cookies aufteilen?

Antwort

2

Ich denke, dass Hyper lieber die Cookies zusammenhält, um es einfacher zu machen, einige Extras mit ihnen zu machen, wie das Überprüfen einer kryptografischen Signatur mit CookieJar (cf. this implementation outline).

Ein anderer Grund könnte sein, die API einfach zu halten. Header in Hyper werden nach Typ indiziert und Sie können nur eine einzelne Instanz dieses Typs mit Headers::get abrufen.

In Hyper würden Sie normalerweise auf einen Header zugreifen, indem Sie einen entsprechenden Typ verwenden. In diesem Fall lautet der Typ SetCookie. Zum Beispiel:

if let Some (&SetCookie (ref cookies)) = response.headers.get() { 
    for cookie in cookies.iter() { 
     println! ("Got a cookie. Name: {}. Value: {}.", cookie.name, cookie.value); 
    } 
} 

Zugriff auf den Roh-Header-Wert von Set-Cookie macht weniger Sinn, denn dann werden Sie eine richtige Analyse von Zitaten und Cookie-Attributen (vgl RFC 6265, 4.1) neu implementieren müssen.


P.S. Beachten Sie, dass in Hyper 10 der Cookie nicht mehr geparst wird. because Die Kiste, die für das Parsing verwendet wurde, löst die OpenSSL-Abhängigkeitshölle aus.

+0

cool, das ist wirklich hilfreich, danke. Ich denke, "hyper" könnte die Kombination der Cookies in einem Header-Feld mit Semikolon Split bevorzugen ... (http://hyper.rs/hyper/async/hyper/header/struct.Cookie.html) –

+0

Gern geschehen! Ja, es ist ein weiterer guter Grund, die Cookies zusammen zu halten, wenn man die Wiederverwendung von Code mit der Server-Seite der Bibliothek angeht. – ArtemGr

Verwandte Themen