| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Those clause are obsolete and never used by common_test.
|
|
|
|
As a first step to removing the test_server application as
as its own separate application, change the inclusion of
test_server.hrl to an inclusion of ct.hrl and remove the
inclusion of test_server_line.hrl.
|
|
|
|
|
|
|
|
|
|
To ease matching of unrecognized header field names we convert them
from case insensitive to the format Sec-Websocket-Version
with capital letters only first and after hyphens.
Earlier only header names up to 20 characters were converted to this
format due to internal buffer limitation. Raising this limit to 50
is a pragmatic solution for existing long header names such as
Sec-Websocket-Version, while valid header names longer than 50 characters
are not very probable.
|
|
This is a slight modification of previous commit by Steve Vinoski
For backward compatibility of old users of decode_packet, I think it's enough
to return error instead of keeping the old line truncation behaviour.
|
|
Allow applications to use a packet_size setting on a socket to control
acceptable HTTP header line length. This gives them the ability to
accept HTTP headers larger than the default settings allow, but also
lets them avoid DOS attacks by accepting header lines only up to
whatever length they wish to allow.
Without this change, if an HTTP request/response line or header
arrives on a socket in http, http_bin, httph, or httph_bin parsing
mode, and the request/response line or header is too long to fit into
a default inet_drv buffer of 1460 bytes, an unexpected error
occurs. These problems were described and discussed on
erlang-questions in June 2011 in this thread:
http://erlang.org/pipermail/erlang-questions/2011-June/059563.html
In the original code, no buffer reallocation occurs to enlarge the
buffer, even if packet_size or line_length are set in a way that
should allow the HTTP data to be parsed properly. The only available
workaround was to collect headers and parse them using
erlang:decode_packet, but that approach has drawbacks such as having
to collect all HTTP header data before it can be handed to
decode_packet for correct parsing, and also requiring each and every
Erlang web server developer/maintainer to add the workaround to his or
her web server.
Change the packet parser to honor the packet_size setting for HTTP
parsing. If packet_size is set, and an HTTP request/response or header
line exceeds the default 1460 byte TCP buffer limit, return an
indication to tcp_remain that it should realloc the buffer to enlarge
it to packet_size. Also fix the HTTP parsing code to properly honor
line_length by truncating any HTTP request/response or header lines
that exceed that setting.
For backward compatibility, default behavior is unchanged; if an
application wants to be able to accept long HTTP header lines, it must
set packet_size to an appropriate value. Buffer reallocation occurs
only when needed, so the original default buffer size in the code is
still the default.
Make the line mode parsing honor packet_size as well, for consistency.
Add new regression tests to the emulator decode_packet suite and also
to the kernel gen_tcp_misc suite.
The documentation for packet_size in inet:setopts/2 is already
sufficient.
Many thanks to Sverker Eriksson for his guidance on how to best fix
this bug and also for reviewing a number of patch attempts prior to
this one.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Packet type 'http' for erlang:deocode:packet and gen_tcp allow a
response line with an empty phrase string, like
"HTTP/1.1 200\r\n".
Earlier, an empty phrase was only accepted if the status code
was followed by space or tab, like
"HTTP/1.1 200 \r\n".
|
|
* se/decode_packet:
Fix erlang:decode_packet(httph_bin,..) to not return faulty header strings
OTP-8548 se/decode_packet
erlang:decode_packet(httph_bin,..) could return corrupt header strings or
even crash the VM. This has been fixed. It only happened on 32-bit VM if
the header name was unknown and between 16 and 20 characters long. Sockets
with simular packet option did not suffer from this bug.
|
|
Unrecognized Http header names was sometimes returned as corrupt
sub-binaries pointing to a stack allocated buffer. This only happened
on 32-bit VM if the header name was between 16 and 20 characters
long. It could in some cases lead to segmentation fault.
The solution was to avoid creating sub-binary if the returned string
was not part of the original binary.
|
|
|
