LINUX.ORG.RU

Восстановить url вида http(s):// из HTTP/1.1 заголовка

 , ,


0

1

Привет, друзья!

Подскажите, пожалуйста, нет ли простого алгоритма восстановления полной ссылки по HTTP/1.1 заголовку? В инете ничего толкового не нашёл, написал свой:

meta['url'] = parser.get_url()
meta['host'] = headers['Host'].split(',')[0]

# specify url
if meta['url'].startswith('http') or meta['method'] == 'CONNECT':
    pass

# https
elif isinstance(self.transport, _SSLProtocolTransport):
    meta['url'] = 'https://' + meta['host'] + meta['url']

# http
elif meta['url'].startswith('/'):
    meta['url'] = 'http://' + meta['host'] + meta['url']
else:
    meta['url'] = 'http://' + meta['url']

Мне не нравится, что он громоздкий получился + в https случае получаю подсказку от транспорта. Может быть есть в стандартных библиотеках что-то полезное? Прошу не предлагать сторонние.

★★

Ответ на: комментарий от vvn_black

Сторонняя, но я её использую. Скажи, пожалуйста. Но хочется независимый от реализации алгоритм, который работает с любым транспортом.

rmu ★★
() автор топика
Ответ на: комментарий от vvn_black

Не совсем то, что мне нужно. У меня нет конечного сервера. Я работаю с пакетами без фреймворков. Мне бы просто алгоритм, не привязанный к транспорту. Например, wireshark всегда при анализе http показывает полную ссылку, но найти его алгоритм в исходниках будет для меня сложной задачей.

rmu ★★
() автор топика

нет. хост + урл. любой запрос к хттп серверу - это хттп-запрос. остальное надо узнавать там откуда ты получил запрос и там может оказаться телнет, а не браузер, или что-то похуже.

вообще тебе надо перед своим бекэндом поставить нжинкс, а не принимать запросы напрямую, от нжинкса ты хттпс скорее всего никогда не получишь. но можешь попробовать попросить нжинкс всегда сообщать тебе абсолютный ури.

anonymous
()
Ответ на: комментарий от anonymous

Спасибо. Уже не первый человек предлагает нжинкс. Для ненагруженного прокси хотел обойтись одним питончиком.

rmu ★★
() автор топика
Ответ на: комментарий от buratino

Нет, я не хочу для этого ставить nginx. Так советуют. Просто хотел более надёжный алгоритм. Но и этот код со всеми вариациями пакетов, что у меня были, справляется. Может быть какой-то случай нестандартный не просчитал?

rmu ★★
() автор топика

Так только транспорт на стороне сервера знает по https пришёл запрос или по http, в остальном протокол идентичен

cobold ★★★★★
()
Ответ на: комментарий от cobold

Раздражает нестандартность http/1.1: у клиентов запросы в мелочах, но отличаются. То ли дело с http/2: вообще таких проблем нет (зато куча других, хи-хи).

rmu ★★
() автор топика
Ответ на: комментарий от t184256

Интересно, что cloudflare, который топит за HTTP/3, в своём блоге показывает, что у HTTP/3 пока не такие и радужные результаты по сравнению с http/2:

For a small test page of 15KB, HTTP/3 takes an average of 443ms to load compared to 458ms for HTTP/2. However, once we increase the page size to 1MB that advantage disappears: HTTP/3 is just slightly slower than HTTP/2 on our network today, taking 2.33s to load versus 2.30s. 
As you can see, HTTP/3 performance still trails HTTP/2 performance, by about 1-4% on average in North America and similar results are seen in Europe, Asia and South America. We suspect this could be due to the difference in congestion algorithms: HTTP/2 on BBR v1 vs. HTTP/3 on CUBIC. In the future, we’ll work to support the same congestion algorithm on both to get a more accurate apples-to-apples comparison.

До твоего «однажды» ещё есть время.

rmu ★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.