Python urllib3 и как обработать поддержку cookie?
Таким образом, я изучаю urllib3, потому что он имеет организацию пула подключений и ориентирован на многопотоковое исполнение (таким образом, производительность лучше, специально для проверки), но документация... минимальна по меньшей мере. urllib2 имеет build_opener так что-то как:
#!/usr/bin/python
import cookielib, urllib2
cj = cookielib.CookieJar()
opener = urllib2.build_opener(urllib2.HTTPCookieProcessor(cj))
r = opener.open("http://example.com/")
Но urllib3 не имеет никакого build_opener метода, таким образом, единственный способ, которым я выяснил до сих пор, состоит в том, чтобы вручную поместить его в заголовок:
#!/usr/bin/python
import urllib3
http_pool = urllib3.connection_from_url("http://example.com")
myheaders = {'Cookie':'some cookie data'}
r = http_pool.get_url("http://example.org/", headers=myheaders)
Но я надеюсь, что существует лучший путь и что один из Вас может сказать мне, каково это. Также может кто-то отмечать это с "urllib3".
3 ответа
Вы правы, на данный момент нет лучшего способа сделать это. Я буду более чем счастлив принять патч, если у вас есть конгруэнтные улучшения.
Следует помнить, что HTTPConnectionPool в urllib3 задуман как "пул соединений" с определенным хостом, а не как клиент с состоянием. В этом контексте имеет смысл держать отслеживание cookies за пределами фактического пула.
- shazow (автор urllib3)
Вам нужно установить 'Cookie' , а не 'Set-Cookie' , 'Set-Cookie' устанавливается веб-сервером.
Файлы cookie являются одним из заголовков, так что в этом нет ничего плохого.
Нет ли проблем с несколькими файлами cookie?
Некоторые серверы возвращают несколько заголовков Set-Cookie, но urllib3 хранит заголовки в dict, а dict не допускает нескольких записей с одним и тем же ключ.
httplib2 имеет аналогичную проблему.
Или, может быть, нет: оказывается, что метод readheaders класса HTTPMessage в пакете httplib, который используют как urllib3, так и httplib2, имеет следующий комментарий:
Если встречается несколько полей заголовка с одинаковым именем, они объединяются в соответствии с правилами RFC 2616 sec 4.2:
Appending each subsequent field-value to the first, each separated
by a comma. The order in which header fields with the same field-name
are received is significant to the interpretation of the combined
field value.
Таким образом, заголовки не теряются.
Однако возникает проблема, если в значении заголовка есть запятые. Я еще не понял, что здесь происходит, но при просмотре RFC 2616 («Протокол передачи гипертекста - HTTP / 1.1») и RFC 2965 («Механизм управления состоянием HTTP») создается впечатление, что любые запятые в заголовке значение должно быть указано.