[erlang-questions] Any tcp related changes in R15B* that might cause this?

[Steve Vinoski]

On Wed, Dec 12, 2012 at 7:24 PM, Anthony Molinaro <
anthonym@REDACTED> wrote:

> Okay, I found it.  Looks like this is the cause
>
> OTP-9389  Honor option packet_size for http packet parsing by both TCP
>           socket and erlang:decode_packet. This gives the ability to
>           accept HTTP headers larger than the default setting, but also
>           avoid DoS attacks by accepting lines only up to
>           whatever length you wish to allow. For consistency,
>           packet type line also honor option packet_size. (Thanks
>           to Steve Vinoski)
>
> With R14B04 when you have a header which is too long, your process
> gets a message like
>
>
> {http,#Port<0.120387186>,{http_error,"X2qutbTBbXg7VHgDDhGrEvDbzuxiyDlI7VFloMyAJKVqY2fTEkMc70UchLPRG8Cjowzmib4KszbCRwA5IBbAd2MbRi5X_tK2nfRtheavXdhQv8XbinzmhCM1E9YCeuFAg_9TfqUS0sWUd52mgjkWGqNe4Z9S0IxFYnFtf5..."}}
>
> in R15B02 you get a message like
>
> {tcp_error,#Port<0.104208233>,emsgsize}
>
> The prior case is handled correctly by mochiweb, the latter is not.
>


I just ran a simple test case against the commit prior to 5984409d and then
against 5984409d, in both cases sending an HTTP header of various lengths,
and in both cases always received http_error, and never tcp_error. The
server simply did a receive with the socket in http_bin mode.

How long is the header in your case? Do you have a test case you can send
me?


I'm not sure if the commits for OTP-9389 actually caused this change or if
> it was some other change.  Also, not sure if it was meant to be a backward
> compatible change or not (the comment on the commit
>
> https://github.com/erlang/otp/commit/5984409d1264871cbe61bfec875de53e51713efb
> seems to suggest it was supposed to be backward compatible, but maybe this
> was a side effect?  It seems like emsgsize is more correct.
>


I think the intent was to be backward compatible; I seem to remember that
putting the patch together was very difficult and time-consuming due to
trying to achieve that, with numerous iterations and reviews.

--steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20121212/7ada0fed/attachment.htm>