The VideoLAN Forums

Posted: **08 Jun 2008 14:59**

Please, could someone that has access to bug-posting, post these bugs (no one ever answered me on IRC channel).

I saw two bugs on the HTML interface :

-1) Minor: Typo on H264: should be h264

Effect: when you use the SOUT interface, if you choose h264 transcode, nothing will be transcoded because VLC is case sensitive and there is no such thing as H264
Location of the bug: on line 176 of file %Install_dir%/http/dialogs/sout
Code: Select all
<option value="H264">H264</option>
Workaround: once you have finished choosing the options with the SOUT-helper, manually replace H264 with h264 in the SOUT string, then save.

-2) Major: misconception with XMLHTTPRequest. Only one global request pointer is used. It means that if the server responds slowly and the user clicks multiple times, the same pointer will be used for subsequent requests. The callback function of the last item clicked could then think its request is finished when the first request sent comes back.

Effect: can produce unreliable behaviour or crashes
Location of the bug: function at line 84 of function.js
Code: Select all
function loadXMLDoc( url, callback )
Workaround: user has to be careful, and wait enough time for every click to fulfill it's action.

This last bug is really bad because it is a misconception of asynchronicity.
When you do an asynchronous action, you must keep memory buffers of your action till it is fully completed.
In this case, author correctly allocates a buffer (new XMLHttpRequest), but:
-a) never deallocates it, relying on GC to do so: which can result in ill written browsers (I.E. !) consuming loads of memory as the request is done repetitively.
-b) all the allocated request are pointed by a unique variable: req. So if there is more than one "living" request, you keep only track of the last one and have no mean to access the previous requests.

There are several ways to make it correct.

What I did is I developped instead of that a linked chain of actions. Each action (corresponding to a click) has its own XMLHttpRequest buffer. Once the action is fulfilled, the buffer goes to "free pool" buffer. When a new action begins, you take a buffer from "free pool", or allocate a new one if "free pool" is out of free buffers.

There are many more ways to correct that.

I'll be glad to contribute... if someone can anwser me on IRC

Posted: **08 Jun 2008 20:55**

1/ should be fixed now on lua http.
2/ well, mail this issue to vlc-devel to get someone (dionoea) fix it.

Posted: **11 Jul 2008 09:32**

Were these bugs fixed? If not when they will be fixed.

Posted: **23 Aug 2008 22:15**

Hi Zahkar, I just saw your post and if you're still willing to do so I would be interested by your help to clean the VLC HTTP interface javascript code.

Posted: **03 Sep 2008 23:06**

Hello happy people,

Since this post is about the HTTP interface, I want to report something 'weird' I had to do in the httpd source.

I'm using VLC 1.0.0-git (from last friday) with the Freeplayer, and the problem was that VLC's http interface was sending the html page OK, but the STB (Freebox HD) wasn't displaying it (well in fact it was, but only when I closed VLC). I checked the ethernet frames and saw that VLC was not sending the FIN/ACK packet the box was waiting for.
After some (looooong) search, I found that it was like having the http connexion's parameter Keep-Alive set, although the STB never use this (not apparent in the captured frame). I read then the httpd source (src/network/httpd.c) and on lines 2353 and following (or around that if it has changed since then) :

Code: Select all

if( ( ( cl->query.i_proto == HTTPD_PROTO_HTTP ) &&
   ( ( cl->answer.i_version == 0 && b_keepalive ) ||
   ( cl->answer.i_version == 1 && !b_connection ) ) ) ||
   ( ( cl->query.i_proto == HTTPD_PROTO_RTSP ) &&
       !b_query && !b_connection ) )
{

This code seems OK (in fact I don't understand 80% of it... ^_^' )
but the two cl->answer in the middle were bugging me and I changed it to the following :

Code: Select all

if( ( ( cl->query.i_proto == HTTPD_PROTO_HTTP ) &&
    ( ( cl->query.i_version == 0 && b_keepalive ) ||
    ( cl->query.i_version == 1 && !b_connection ) ) ) ||
    ( ( cl->query.i_proto == HTTPD_PROTO_RTSP ) &&
       !b_query && !b_connection ) )
{

and now it's working perfectly
Is it a 'bug', or did I break something in the httpd code ?

Posted: **23 Sep 2008 01:45**

I'm not entirely sure what's going on here, and I'd like to see a trace (ethereal or something) of the HTTP requests/replies that are going on between VLC and the Freeplayer box.

Your change does not seem logical to me, even though it might fix your problem. With protocol 1.0 a connection should stay open only if Keep Alive is send. With 1.1 it should only close when Close it send and otherwise stay alive. As far as I know we should always base our decision on how the client last answered, and such the original code seems OK. It might be that we do something else wrong earlier in the communication and a logging of the HTTP communication might be able to show the problem.

Posted: **23 Sep 2008 20:41**

Hello,

aahhhh at last an answer

OK for the keepalive vs close system, but (to me) it seems that the httpd is sending 1.1 protocol whatever the client asks, although it should answer with the requested protocol, no ?
here are two captures (done with wireshark)
http://malbach.free.fr/Wireshark_vlc0.8.6
http://malbach.free.fr/Wireshark_vlc1.0.0git

with vlc 0.8.6, we can see the GET is done with HTTP/1.0 (frame 4), and with vlc 0.8.6 the answer is in HTTP/1.0 too (frame 8 )
but with vlc 1.0.0-git (and almost sure that 0.9 is the same) the GET is HTTP/1.0 (frame 17) but the answer is HTTP/1.1 (frame 21)
So with the freebox never sending 'Close' because it only uses HTTP/1.0, the connexion stays open and the freebox waits forever

I have also a new capture done with vlc1.0.0-git and firefox3 that I made after reading your post, DJ, 'cause I was afraid of having broken the code for HTTP/1.1 connexions.
http://malbach.free.fr/Wireshark_vlc1.0.0git_ff3
but it's still working, as it seems

As said before I don't understand it completely now, but I'm searching and reading through it, and so I can be wrong

EDIT

As far as I know we should always base our decision on how the client last answered, and such the original code seems OK.

IMO, the client makes queries, not answers, right ? this is what's troubling me...
If I understand good, in the original code it is the answer's protocol that is used to decide to close or not the connexion
but the answer is done by the server, no ? at least the cl->answer structure is based on what the server will send to the client, isn't it ?

Posted: **23 Sep 2008 23:43**

Thanks i'll look into it tonight (i hope).

Posted: **24 Sep 2008 02:58**

Thanks i'll look into it tonight (i hope).

Based on your debug output as well as your comments and further reading of http://www.ietf.org/rfc/rfc2145.txt I have decided that your patch is valid and should be applied. http://git.videolan.org/?p=vlc.git;a=co ... 4729a85463

The VideoLAN Forums

Bugs with the HTML interface

Bugs with the HTML interface

Re: Bugs with the HTML interface

Re: Bugs with the HTML interface

Re: Bugs with the HTML interface

Re: Bugs with the HTML interface

Re: Bugs with the HTML interface

Re: Bugs with the HTML interface

Re: Bugs with the HTML interface

Re: Bugs with the HTML interface