[FFmpeg-devel] [PATCH]Add one CRLF to http headers if necessary

[Nicolas George]

L'octidi 8 ventôse, an CCXXIII, Derek Buitenhuis a écrit :
> This does not necessarily work on windows. The C standard idctates that in
> text mode, \n is translated to the system's native newline.
> 
> Use memcpy and 0x0D / 0X0A / 0x00.

I think you are confusing two subtly different issues and getting the result
wrong.

The first issue is that the C standard does not specify the byte value of
'\n' and '\r', the most notable example being macos<10 where '\n' is 0x0D
instead of 0x0D everywhere else because apple never does anything like
everyone else. But they still translate into a single byte value each, and
POSIX specifies that '\n' = 0x0A and '\r' = 0x0D.

The second issue is that with the windows file API, when the file is opened
in the so-called "text mode", there is an implicit conversion between '\n'
in memory (which is actually exactly 0x0A) and "\r\n" in the file; there is
also a conversion between 0x1A and EOF. It only happens with file I/O
operations, not with simple string operations, even sprintf. On Unix, a
similar conversion happens in the TTY layer. The TTY layer is something
nobody should touch without a long pole and a hazmat suit; on windows, the
hazmat is littered all over the API.

Therefore, I believe Carl Eugen's original patch was technically correct.

> This may also accidentally allow for headers to end with '\n\r\n',
> wouldn't it?

Well, the test as it is is half-assed, it checks for a specific common
mistake but does not actually validate the format of the string.

I am not in favour of fixing the shortcomings of the user's shell in
FFmpeg's libraries, but if it is considered useful, I believe a more
complete approach should be used: replace all occurrences of \n with CRLF,
validate folded headers, etc.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20150226/fd0f2968/attachment.asc>