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

[Nicolas George]

Le primidi 21 ventôse, an CCXXIII, Michael Niedermayer a écrit :
> If the user passes just one header "line" then either he adds
> CRLF at the end or he doesnt. These 2 cases can be easily distnguished
> and teh code can add CRLF if its missing
> this is basically carls patch and i think its good and simplifies
> useage,

For the case of a single line, I do not disagree. OTOH, I would prefer to
see it implemented that way:

    if (need_extra_crlf)
	len += av_strlcpy(headers + len, "\r\n", sizeof(headers) - len);

In other words: add the missing CRLF on the fly when using the s->headers
option.

> The case of multiple header lines is trickier, http uses CRLF as

Let us focus on that one please.

> seperator IIRC. My idea was to be a bit more flexible here and allow
> any line ending character and normalize these to CRLF before sending
> them. This is your first patch i belive.

True, that was my first patch.

> This would allow users to just use a quote and the enter key after each
> header i assume on the command line. While in a textfield of a GUI
> it can be entered easily 1 line per header.
> Maybe iam missing something here but it seems convenient to allow
> this than to strictly require CRLF

In short: this is an API and an API must be strict. This is not just a
hollow principle that I want to apply blindly. Once we document this is
accepted, people will start to use it, and we will be stuck with it, we must
maintain it and keep compatibility until at least two major bumps. This is
the same reason for writing ">= for success" even if the function returns
only 0: MAYBE sometime later we will want to expand, and in that case it
will be an advantage to us.

Of course, it has to be balanced with the benefits for the users.

First, I would like to emphasize that the HTTP headers option would have the
AV_OPT_EXPERT flag if it existed in lavu and not only in cmdutils.

Now, let us see the various uses of the option and the corresponding
benefits.

For an application that builds the HTTP headers string from various sources:
benefit: 0. A delimiter string is a delimiter string, whether it is "\n",
"\r\n", five exclamation marks or an ASCII-art tortoise.

For the GUI application that you suggested earlier, and similar
applications: First, I consider them rather unlikely: exporting an expert
option in a GUI with a simple text entry is way too fragile. Still, let us
admit it exists. It must do a special case for HTTP headers, since it is a
multi-line field. In that case, doing a special case for sanitizing the
string is not too much to ask. Of course, lavu can help: I would have no
objection to some kind of "av_string_normalize_line_breaks(&str)" to do the
actual work.

For command-line applications accepting the options directly from the user:
For Unix shells: benefit: the user can hit return without hitting Ctrl-V
Ctrl-M before, two extra keys. Not much.
For the windows shell: benefit: 0. I suspect hitting return with unclosed
quotes will not have the desired effect. And CRLF is the native windows line
ending anyway.

The global benefit, as I see it, is rather feeble.

I can propose a middle ground:

Normalize line endings, but still print a warning.

That way, lazy users can spare the few keys, but we are free to break it if
we need/want.

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/20150316/e26b5625/attachment.asc>