If we want to keep a conservative default, we could perhaps make this an option instead.

This seems to address a similar issue to #123.

I think increasing the default buffer is a potentially dangerous thing to do as it will increase the upfront cost of accepting a connection therefore harming scalability, while simultaneously also make it easier for DoS'ing the overlying software. That said, maybe taking a peek, and grow approach that checks the length of the header (if present) and increasing the buffer accordingly is a better approach. WDYT @emersion @bollenberger?

UPDATE

I have opened #150 as an alternative to statically resizing the buffer as proposed here.

I think there are two separate concerns here:

• "increase the upfront cost of accepting a connection therefore harming scalability": indeed, bumping the bufio.Reader size to 4k increases the memory footprint of each connection. Getting rid of the Peek call would make it possible to read larger headers without allocating 4k upfront. I have a patch sitting in a local branch to do that, will update the PR accordingly shortly.
• "make it easier for DoS'ing the overlying software": all TLVs are read into memory, so bumping the max header size to 4k will make it slightly easier to DoS a server. Do you think this concern warrants keeping the current 256 byte limit as default, and adding an option to bump it? I personally think 4k is still quite low so I think it would be fine to just use that limit by default, but I'd be fine with adding an option as well.

@emersion I have opened #150 as an alternative to statically resizing the buffer as proposed here.

I've posted yet another alternative in #155.

Closing in favor of #155.