[streaming] How to answer to PROPFIND request issued by VLC 1.0.x when VLC requesting a video stream file ?

[AlainPierre.Chertier at zodiacaerospace.com]

Hello,

I don't know if I post this message in the right place, so please excuse 
me if not so...

I'm currently developping an embedded HTTP server which will have to serve 
recorded or on-the-fly
video files/streams to a VLC client (and other clients, may be, like WMP, 
Quicktime, RealPlayer, etc...)

All was fine with VLC 0.9.9, doing a simple GET request served very fine 
by my HTTP server.
Now it is not ok anymore since version 1.0.0 of VLC which I don't 
understand its new way
of preparing a client streaming session. I tried to compare Ethernet 
captures done by using Wireshark
while VLC is adressing its request to an Apache server or to my embedded 
HTTP server to get and
display a "test.mpg" video stream file (Apache is ok but not my own 
embedded HTTP server...).


(1) VLC 1.0.0 <=> Apache capture :

request #1:    OPTIONS / HTTP/1.1
answer #1:    HTTP/1.1 200 OK with additional fields, notably "Allow: 
GET,HEAD,POST,OPTIONS,TRACE"

ok, Apache informs the VLC client that it is supporting 
GET,HEAD,POST,OPTIONS and TRACE requests only
(so it seems Apache not supporting PROPFIND requests)

Then, VLC 1.0.0 will continue to talk with the Apache server without 
issuing any PROPFIND request...

request #2:    OPTIONS /test.mpg HTTP/1.1
answer #2:    HTTP/1.1 200 OK   (followed by additional fields about 
"test.mpg" file characteristics, ok)

request #3:    GET /test.mpg HTTP/1.1

request #4:    GET /test.mpg HTTP/1.1     (followed by additional fields, 
notably further offset in the requested file, being already partly 
received...)

answer #3:    HTTP/1.1 206 Partial Content (video/mpeg)

request #5:    GET /test.mpg HTTP/1.1     (followed by additional fields, 
notably further offset in the requested file, being more nad more partly 
received...)

answer #4:    HTTP/1.1 206 Partial Content (video/mpeg)

and "test.mpg" file streaming/displaying is running ok from beginning to 
end without any problem...


Now, let's try with my own embedded HTTP server, which seems to not work 
anymore, that is, not working as expected by VLC 1.0.x !?

(2) VLC 1.0.0 <=> embedded HTTP server capture :

request #1:    PROPFIND /test.mpg HTTP/1.1
answer #1:    HTTP/1.1 200 OK    (but I don't know what additional fields 
I shall add ?)
  .
  .
  .
VLC tries again with more than one PROPFIND request,
  .
  .
  .
Then VLC will finally issue GET request(s) and the HTTP server will 
transfer whole "test.mpg" file blocks to the VLC client
which stays in a strange and long time-out period (between 5 and 10 
minutes ?), and then VLC is displaying
the requested video stream file perfectly !? What's the matter ???

What status message shall I construct to answer to PROPFIND requests ? It 
seems that VLC 1.0.x version
is using some Microsoft WebDAV module issuing at least a PROPFIND request 
as 1st request when talking to my
own embedded HTTP server, but issuing standard OPTIONS requests when 
talking to an Apache server !?

What I don't understand is the difference of 1st request to Apache ( = 
OPTIONS request) and to my own-developped
embedded HTTP server ( = PROPFIND request, which I don't know how to 
answer to exactly !? ). How VLC makes the
difference, not issuing the same 1st HTTP request when requesting the 
"test.mpg" file from an Apache server or
from my own embedded HTTP server ??? Can it be a "king of magic" ? I don't 
think so, naturally...

Having no problem with VLC prior to v1.0.x and no problem with Windows 
Media Player v11.xx client,
so asking my customers / users to use VLC v0.9.9 at this time, 
waiting/hoping me to solve the problem ASAP...

1st look at WebDAV RFC is not very clear, still don't know what exactly to 
add as sub-fields when
constructing answer to PROPFIND request (sub-fields like "Content-Lengh:", 
"Content-Type:", "Allow:", etc...) ? 

Many thanks in advance for any help/suggestion about trying to solve this 
unattended problem.
King regards.

Alain-Pierre
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/streaming/attachments/20090803/73c0b305/attachment.htm>