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

Michael Niedermayer michaelni at gmx.at
Wed Mar 11 12:57:50 CET 2015


On Tue, Mar 10, 2015 at 02:09:10PM +0100, Nicolas George wrote:
> Le decadi 20 ventôse, an CCXXIII, Carl Eugen Hoyos a écrit :
> > Please add a reference to ticket #3268 
> > to the commit message.
> 
> I was about to reply "locally added", but no, because it does not fix that
> ticket.

what is the problem ?
can you elaborate?


> 
> Re-thinking on the whole discussion, I withdraw this patch, it is wrong. This
> part of the code is an API, not an UI, so it is better if it is strict. I
> will try to propose another patch for pure validation.
> 
> Regarding the trac ticket itself, I wrote this, and I stick to it:
> 
> # I am not in favour of fixing the shortcomings of the user's shell in
> # FFmpeg's libraries
> 
> # If we are talking about end-user interface, the changes should happen in
> # cmdutils.c.
> 

> In other words, I vote for closing #3268 as WONTFIX and suggesting windows
> users to use a better shell (maybe the so-called powershell introduced in
> the recent windows versions can do it).

theres a bug in OUR code it should be fixed in our code.
The line ending characters differ between platforms and users do in
general not know about these differences nor should they need to.
the command line input will in the overwhelming number of cases be
in the platforms native "line ending encoding". the strings passed
on API level will certainly often be in the platforms native encoding
as well, in the case of headers they might be in the CRLF encoding
too, and considering that these are generic options, some applications
will export them generically and not have special cases to re encode
the strings, and i think quite independant of the option passing API.


> 
> If people really want to fix microsoft's shortcomings in FFmpeg, then it
> must happen in the UI, not the API, i.e. in cmdutils.c. Maybe something like
> that: "ffmpeg ... -expand -headers 'Cookies: chocolate\r\n'" (-expand being
> a new option meaning "perform escape-character expansion on the following
> option argument"). But I do not intend to work on it, because anybody can
> get a shell where $'\r\n' works.

I think thats alot of effort on the users part you ask here for

IMO
User interfaces should be designed so they do what the user wants with
minimun effort on the users part.
Aka i belive its not the human who should have to adapt to interface
to a computer (in the extreemest case that would be flipping bits one
by one in memory) but rather the computer should adapt to how humans
interact where it is possible and works reliable


[...]


-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 1
"Used only once"    - "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20150311/e42b900b/attachment.asc>


More information about the ffmpeg-devel mailing list