On Sat, May 30, 2015 at 10:13 AM, Nicolas George <geo...@nsup.org> wrote: > Le decadi 10 prairial, an CCXXIII, Stephan Holljes a écrit : >> Should method be reassigned or should the set value be kept? As far as >> I can tell the only way to set method is by specifying it as an option >> in the command line. >> I don't think overwriting specific values set by the user is good. >> Maybe output a warning? > > Until now, the option was used for client code only, not for server. > Therefore, you have to decide how you want to use the option for server > code, and document it. > > You can use it to return to the application the method the client used. > Output-only options already exist elsewhere in the code. In that case, a > warning if the option is already set is a good idea. > > Or you can use to let the user specify the expected request, and have the > server code reject clients with an error if it does not match. > > Or you can find other uses I did not think of. I suspect you need to think > ahead about the "avio_accept()" API, and in particular how it will return > the address of the incoming client, since the request method is part of > "HTTP address".
After looking at the ffserver code, I'm wondering if maintaining a list of clients as HTTPContext or custom wrapper structs would make sense. For the time being it would only contain the singular client context which can be accepted right now, but in the future could contain an arbitrary number of clients. Before I start implementing that I would like to know if it is a good choice to do this. > > Regards, > > -- > Nicolas George > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
