[FFmpeg-devel] [PATCH]Add one CRLF to http headers if necessary
Derek Buitenhuis
derek.buitenhuis at gmail.com
Thu Feb 26 16:52:40 CET 2015
On 2/26/2015 3:35 PM, Nicolas George wrote:
> 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.
I read it as a 'text stream', which isn't necessarily file i/o only, but I doubt
it is worth bikeshedding over.
> Therefore, I believe Carl Eugen's original patch was technically correct.
See below.
>> 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.
Yes it's pretty bad, more on that below.
> 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.
I think relying on the user to input a CR+LF cia command line program is
insane in the first place... shouldn't the library do that / join headers
properly?
- Derek
More information about the ffmpeg-devel
mailing list