On Wed, Aug 19, 2015 at 7:59 PM, Stephan Holljes <klaxa1...@googlemail.com> wrote: > On Thu, Aug 20, 2015 at 12:11 AM, Ganesh Ajjanagadde <gajja...@mit.edu> wrote: >> On Wed, Aug 19, 2015 at 12:14 PM, Stephan Holljes >> <klaxa1...@googlemail.com> wrote: >>> --- >>> libavformat/http.c | 8 ++++++++ >>> 1 file changed, 8 insertions(+) >>> >>> diff --git a/libavformat/http.c b/libavformat/http.c >>> index a136918..4dbef3f 100644 >>> --- a/libavformat/http.c >>> +++ b/libavformat/http.c >>> @@ -348,11 +348,19 @@ static int http_write_reply(URLContext* h, int >>> status_code) >>> reply_text = "OK"; >>> content_type = "application/octet-stream"; >>> break; >>> + case 301: >>> + reply_code = 301; >>> + reply_text = "Moved Permanently"; >>> + break; >> >> 301 is usually used for URL redirection, >> and you don't seem to do anything beyond setting the message. >> There needs to be additional logic somewhere to handle this. >> Nevertheless, it is still ok as a patch to me, >> since I assume this will be handled later on. >> I strongly suggest adding something to clarify this in the commit message. > > I did not think about that and so far I have only used it in my > modified ffserver code. What makes a 301 reply different from the > other replies? Maybe I didn't understand the RFC correctly.
Quoting from the RFC: "The new permanent URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s). " My point is that somewhere in the response a new URI must be provided, so that the client can go to the redirected location. I don't know where/how such logic should go, but it needs to be done. > >> >>> case AVERROR_HTTP_SERVER_ERROR: >>> case 500: >>> reply_code = 500; >>> reply_text = "Internal server error"; >>> break; >>> + case 503: >>> + reply_code = 503; >>> + reply_text = "Service Unavailable"; >>> + break; >> >> Looks ok to me. >> >>> default: >>> return AVERROR(EINVAL); >>> } >>> -- >>> 2.1.0 >>> >>> _______________________________________________ >>> 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 > _______________________________________________ > 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
