Het Bijstere Spoor

To make FLV's coming from flash streaming servers (FCS/FMS/Red5) properly work as a progressive download, it's often required to use a tool to inject 'missing' meta-data.

Up until now I used FLVTool2 for this, but it seems to load the entire FLV into memory (badd!), and now I'm getting nasty errors as well..

I wanted to try out FLVTool++ anyway, as it seems like a much more scalable solution.. This is how its installed on debian:

Grab the source:

Unpack

Make sure you have a compiler installed (as root).

Compiling

AArrghh! It doesn't compile :(. This is the error it gave me:

Ok, lets dig into this code a bit.. the errors seems to give a few useful hints..

First thing I did was go to line 35 in AMF.h and change:

into:

Next, open flvtool.cpp (line 192) and change:

Into:

Now, for some reason you also need to manually create the bin/ directory in your source directory, after that you can start compiling again.

Success! Your bin/ directory will now contain the flvtool++ binary

httpOnly cookies allow you to hide your (session-)cookies from javascript. In the case of an XSS hole in your application, it will make a hackers life much harder to steal someones session.

Internet Explorer support httpOnly cookies for a long time, but since version 2.0.0.5 Firefox also supports this feature. Apparently Mozilla hasn't openly promoted this new feature yet, because its still possible to fetch the cookies with XMLHttpRequest. PHP has support for httpOnly cookies and sessions since 5.2.

• Article link
• More on httpOnly

I figured, the best way to come up with a usable PHP-RPC spec, is to put it in practice, and see where the problems appear. This is to prevent putting 'academical correctness' before usefulness.

So, I created a server implementation, and so far it works well. It's under a bsd license, so feel free to give it a shot. Right now I put everything in the 'Sabre' package, hopefully at one point this will be Zend, PEAR2 or Solar, but I'll look at that when I can put the 1.0 stamp on it. This implementation is only tested with PHP 5.2 and 5.1.

download link

The server class:

A sample client:

Here's the updated proposal. Changes have been highlighted.

The proposal (0.2)

Goals

• Client should be very easy to implement. Server is allowed to be a bit more complex.
• No duplication of the HTTP protocol. For example, HTTP already provides encryption, redirecting and authentication.
• PHP 4/5/6 compatiblity.
• Client and server implementations should be built from the idea 'be strict in what you produce, be liberal in what you accept'

The request

Requests are made using either GET or POST. Both should be accepted. GET is more appropriate for fetching information, whereas POST is used for posting new data. POST has the advantage that it doesn't have any limits in the size of the request and an encoding can be supplied. GET has the advantage that information can be fetched using a one-liner.

When there is no encoding specified, UTF-8 is assumed. Data supplied using POST should be encoded as application/x-www-form-urlencoded (this is how a browser submits data by default).

The method thats called should always be supplied as the 'method' variable. The method can contain periods (.) to seperate namespaces like XML-RPC. Arguments can be specified in two ways, and the API documentation should specify what the appropriate way is. The first way is using named arguments, a GET example would be:

The method here is getUsers, the named argument is maxItems and its value is 20.

The second way is using a list of arguments, which might be more appropriate in some cases where you want to directly map services and methods from a class on the server to the api. This is also how XML-RPC works.

The first argument is 20, the second is 1.

Smart clients should autodetect if the user is trying to use named arguments or a sequence by checking out the type of the keys in the array.

Smart servers should use reflection to automatically map named arguments to the actual arguments in a list.

Clients SHOULD supply the version of PHP they are running. This can be either a complete version number, or just the major version (e.g.: 4, 5, 6). Clients should supply this as the phpVersion parameter. If the versionnumber is not supplied, the current stable PHP version is assumed, which is at the time of writing 5.

Clients MAY also supply the version of the PHP-RPC protocol as the 'version' parameter. Currently this is 0.2.

Clients MAY supply a returnClasses parameter. The value for returnClasses is either 0 or 1 and this can tell the server if the client is aware of typed objects that might be sent from the server.

The server

The server MUST allow requests both GET and POST requests. The server MUST treat any incoming text without encoding as UTF-8.

The server SHOULD allow both named arguments and indexed arguments for methods where this is possible.

If the client sent phpVersion the server MUST convert the returned serialized string so it can be read by the server. If the phpVersion is 4 or 5 the server MUST convert all unicode-strings (type U) to binary strings (type s). If the phpVersion is 4 the server MUST convert all private and protected properties to public properties.

Servers SHOULD also convert all typed objects to either STDClass'es or arrays when the client supplied returnClasses is set to 0, if this is appropriate.

I'm fairly sure I will remove the following paragraph. If PHP gets an HTTP 500 on a file_get_contents, it will throw an error, which removes the possibility to easily grab the error message.

When the method-call was successful the server should send HTTP code 200. When an error occurred the server should send an appropriate HTTP error code. (for example 400 for missing arguments, 500 for unexpected exceptions, 401 if the user should authenticate itself first and 403 is the method was not allowed to be called).

The return data is always in PHP's serialize data format. The Content-Type header should always be 'application/x-php-serialized'

FITC presentation videos are online, including mine. Its the first time I actually watch it. It's a bit creepy to see myself, but I guess it went fine. I couldn't get a mic hooked up at the time, so the audio quality is a bit crappy.

I also notice that I made a bunch of mistakes related to embedding swf's, which I only found out later.

A funny fact: The girl sitting right in the front (and leaves after a while) is now my girlfriend. So we actually have video footage of when we first met :).

For those of you who are not following the PHP internals mailing list, the namespaces subject has been brought up again, with a simple implementation from Dmitry Stogov.

Its hard to say if it actually gets integrated in the source, as its a touchy subject and many implementations have came before this; but I love the way its implemented.

Quotes from Dmitry:

Namespaces are defined the following way:

1. <?php
2. namespace Zend::DB;
3.  
4. class Connection {
5. }
6.  
7. function connect() {
8. }
9. ?>

Namespace definition does the following:
All class and function names inside are automatically prefixed with namespace name. Inside namespace, local name always takes precedence over global name. It is possible to use the same namespace in several PHP files.
The namespace declaration statement must be the very first statement in file.

Every class and function from namespace can be referred to by the full name
- e.g. Zend::DB::Connection or Zend::DB::connect - at any time.

1. <?php
2. require 'Zend/Db/Connection.php';
3. $x = new Zend::DB::Connection;
4. Zend::DB::connect();
5. ?>

Namespace or class name can be imported:

1. <?php
2. require 'Zend/Db/Connection.php';
3. import Zend::DB;
4. import Zend::DB::Connection as DbConnection;
5. $x = new Zend::DB::Connection();
6. $y = new DB::connection();
7. $z = new DbConnection();
8. DB::connect();
9. ?>