I investigated a little more, with a WireShark capture during the data transfer.

The result is that when the server sends the data to the client, on the wire I see a sequence of the following:

Secure Sockets Layer

TLSv1.2 Record Layer: Application Data Protocol: http-over-tls
    Content Type: Application Data (23)
    Version: TLS 1.2 (0x0303)
    Length: 280
    Encrypted Application Data: b3f311d05739fe9f68e8b989c7e16e6989bb1073ccbd72e8...
TLSv1.2 Record Layer: Application Data Protocol: http-over-tls
    Content Type: Application Data (23)
    Version: TLS 1.2 (0x0303)
    Length: 280
    Encrypted Application Data: b3f311d05739fea05d1801defa114bac34bed67bcb979f45...
TLSv1.2 Record Layer: Application Data Protocol: http-over-tls
    Content Type: Application Data (23)
    Version: TLS 1.2 (0x0303)
    Length: 280
    Encrypted Application Data: b3f311d05739fea1caf72a89234756d20634fc35a642aae8...
TLSv1.2 Record Layer: Application Data Protocol: http-over-tls
    Content Type: Application Data (23)
    Version: TLS 1.2 (0x0303)
    Length: 280
    Encrypted Application Data: b3f311d05739fea26100c1886de1772f58ffc6d82857750f...


I don't know exactly how long is the SSL header, but 280 is pretty close to 256...

On the contrary, when my client sends back a big file, what I see is this:

Secure Sockets Layer

TLSv1.2 Record Layer: Application Data Protocol: http-over-tls
    Content Type: Application Data (23)
    Version: TLS 1.2 (0x0303)
    Length: 16408
    Encrypted Application Data: 50678c1059ce995ac6e2bad093310c76f827d38d2ddfff1b...


So the length is the default record buffer.

Given this I can suppose that the tokenizer is on the server side... do you know any implementation detail of your library that might lead to this behaviour?