the emited code that initializes local variables did not handle
unaligned data causing stack corruption, affecting code like:
void main(void)
{
char a[9] = {0};
}
this change will emit code that does byte stores for the unaligned
bytes and also handles small objects (<= 16 bytes) without branches.
tlsClient() now can optionally send the server_name in the ClientHello
message by setting the TLSconn.serverName. This is required for some
https sites.
using /proc/$pid/mem to access vga bios is not portable and crashes
sgi machines when aux/vga is run. instead, try /dev/realmodemem
first (provided by realemu), then #v/vgabios.
this allows extracting tar archives that use longnames extension,
where the real filename is stored in a special entry with
linkflag == 'L' before the file entry. also skip longlink entries
with linkflag == 'K'.
The mode printed under the -l option contains 11 characters,
interpreted as follows: the first character is
d if the entry is a directory;
a if the entry is an append-only file;
- if the entry is a plain file.
Therefore, handle them in automatically generated directory listings.
David du Colombier wrote:
> The slowness issue only appears on the loopback, because
> it provides a 16384 MTU.
>
> There is an old bug in the Plan 9 TCP stack, were the TCP
> MSS doesn't take account the MTU for incoming connections.
>
> I originally fixed this issue in January 2015 for the Plan 9
> port on Google Compute Engine. On GCE, there is an unusual
> 1460 MTU.
>
> The Plan 9 TCP stack defines a default 1460 MSS corresponding
> to a 1500 MTU. Then, the MSS is fixed according to the MTU
> for outgoing connections, but not incoming connections.
>
> On GCE, this issue leads to IP fragmentation, but GCE didn't
> handle IP fragmentation properly, so the connections
> were dropped.
>
> On the loopback medium, I suppose this is the opposite issue.
> Since the TCP stack didn't fix the MSS in the incoming
> connection, the programs sent multiple small 1500 bytes
> IP packets instead of large 16384 IP packets, but I don't
> know why it leads to such a slowdown.
apache sends Content-Encoding: gzip header for Content-Type: application/x-gzip
causing hget to decompress tgz files.
from the w3c:
The Content-Encoding entity-header field is used as a modifier to the media-type.
When presented, its value indicates what additional content codings have been applied
to the entity-body, and thus what decoding mechanisms must be applied in order to
obtail the media-type referenced by the Conent-Type header field. Content-Encoding
is primarily used to allow a document to be compressed without losing the
identity of its underlying media type.
this is clearly silly, as the file is already compressed, and decompressing it
will not yield the indicated Content-type: application/x-gzip, but a tarball.
examples:
http://zlib.net/zlib-1.2.8.tar.gzhttps://www.mirbsd.org/MirOS/dist/mir/mksh/mksh-R50f.tgz
