- 1
- 2
>> # HTML/4.01 says that line breaks are represented as "CR LF" pairs (i.e., `%0D%0A')
>> $content =~ s/(?<!%0D)%0A/%0D%0A/g if defined($content);-
Perl / Говнокод #13605
−139
HTTP::Request::Common 6.04, строка 86
http://cpansearch.perl.org/src/GAAS/HTTP-Message-6.04/lib/HTTP/Request/Common.pm
Оно просто берёт и изменяет передаваемый контент. Любой. В том числе просто бинарные данные.Запостил:
kainwinterheart,
13 Августа 2013
Follow us!
а откуда у тебя бинарные данные в HTTP запросе? в ответе я понимаю, но с бэйс64/етц народ трахается именно потому что запрос должен быть текстом. (или мои знания HTTP совсем устарели?)
P.S. вроде не так сильно устарели:
http://www.w3.org/TR/html401/interact/forms.html#h-17.13 для случая "multipart/form-data" ссылается на:
http://www.rfc-editor.org/rfc/rfc2045.txt который в 6.2 говорит что:
> As of
> the initial publication of this document, there are no standardized
> Internet mail transports for which it is legitimate to include
> unencoded binary data in mail bodies. Thus there are no
> circumstances in which the "binary" Content-Transfer-Encoding is
> actually valid in Internet mail.
другими словами, base64 все еще остается единственным способом посылать двоичные данные в запросе.
HTTP, емнип, нигде не требует.
Но портят данные они не из-за HTTP, а, внезапно, из-за HTML 4.01, которое в пункте 17.13.4 Form content types говорит нам: "Line breaks are represented as "CR LF" pairs (i.e., `%0D%0A')."
Имхо тут надо было бы какую-нибудь опцию, позволяющую работать в двух режимах - raw и html-compatible. Ибо на HTML свет клином не сошелся.
P.S. А все-таки. Почему не подошел multipart/form-data?
- Хотя бы. С другой стороны, оно же не для работы с HTML, а для работы с HTTP. Причём тут вообще HTML у него - остаётся загадкой.
>> Почему не подошел multipart/form-data
- Используем Kyoto Tycoon, а в него если писать данные http-запросом вместо memcached-протокола или же его собственного бинарного протокола, то оно не понимает post с multipart/form-data.
Основной юзкейс HTTP как бы, вот все под него и затачиваются, в ущерб остальными применениям...
> Используем Kyoto Tycoon
Понятно, т.е. протокол так требует.
еще раз: какие в ж@пу *двоичные* данные в *urlencoded* формате?
КЭП в отпуске, очевидно.
Эм, а почему вы ориентируетесь на это RFC? RFC 2616 (HTTP 1.1 от 99 года) говорит об обратном.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec19.html#sec19.4.5
19.4.5 No Content-Transfer-Encoding
HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC 2045. Proxies and gateways from MIME-compliant protocols to HTTP MUST remove any non-identity CTE ("quoted-printable" or "base64") encoding prior to delivering the response message to an HTTP client.
Т.е. если кто-то и применяет там base64, то применяется оно на прикладном уровне, а не на уровне HTTP протокола, где его использование вообще запрещено.
Вообще, если по-хорошему, то все документы которые для чего бы то ни было предписывают использование бейс64 нужно пытаться устранить как-нибудь. Это идитское требование совершенно несоответствующее современным жизненным реалиям.
Если в http включить gzip, а включать его надо, то хаффман вернет обратно практически треть оверхеда.
Правда на реквесте не получится, да
Нафига их передавать через текстовые каналы?
А ответ бинарными данными?
Второе (чуть более реальное) применение - аттачи в почте до сих пор как-то так должны кодироваться.
А, чуть не забыл, тоже верх упоротости. У меня на работу есть RDP, но отключена передача файлов. Прямого доступа нет, та машина не в инторнетах, потому мелкие файлы я кодирую в base64, потом передаю через стандартный буфер обмена, а там распаковываю.