Fix a small typo: you are instead of your are
Merge pull request #21 from oligot/typo

Fix a small typo: you are instead of your are
Cross-Origin Resource Sharing initial support

Initial support for the Cross-Origin Resource Sharing specification.
This allows JavaScript to make requests across domain boundaries.

Also reviewed the filter example to get rid of the context and
the generic classes (we can actually use {WSF_REQUEST}.execution_variable
and {WSF_REQUEST}.set_execution_variable).

Links:
* How to enable server-side: http://enable-cors.org/server.html
* Specification: http://www.w3.org/TR/cors/
* Github: http://developer.github.com/v3/#cross-origin-resource-sharing
Filter example: all libraries are now readonly
Merge pull request #23 from oligot/readonly-ecf

Filter example: all libraries are now readonly
Added {HTTP_HEADER}.put_header_key_values

This is mainly a refactoring that is useful for an upcoming PR
regarding CORS (smaller patches are better...)

Note that this also fixes a small typo where an extra space was
added when calling {HTTP_HEADER}.put_allow
Merge pull request #24 from oligot/header-values

Added {HTTP_HEADER}.put_header_key_values
Minor optimization in HTTP_HEADER
Use execution_variable instead of context

This is mainly to be compatibe with other classes API.

In a lot of classes, we define methods like this:
```Eiffel
 method (req: WSF_REQUEST; res: WSF_RESPONSE)
    do
        ...
    end
```

With the context, the signature becomes:
```Eiffel
 method (ctx: C; req: WSF_REQUEST; res: WSF_RESPONSE)
    do
        ...
    end
```

So, I can't build a filter chain where one filter is with context
and one is without context (I can't call
WSF_FILTER.set_next (a_next: WSF_FILTER) with a filter that is a
descendant of WSF_CONTEXT_HANDLER).

Moreover, having to play with generic types just to pass some
data from one filter to another is a bit overkill imho.
Because this is really what I use contexts for:
to pass data from one filter to the next one.

Regarding execution_variable and strong typing, if we want to achieve these,
I realize we could write a class with one getter and one setter like this:

```Eiffel
  class
    TYPED_DATA

  feature -- Access

  user (req: WSF_REQUEST): detachable USER
    do
        if attached {USER} req.execution_variable ("user") as l_user then
            Result := l_user
        end
    end

  feature -- Element change

  set_user (req: WSF_REQUEST; a_user: USER)
    do
        req.set_execution_variable ("user", a_user)
    end
```

Now, I realize this is a major change since the last time we talked about this,
but at the end, after having played with both, I prefer the one with
execution_variable.
Merge pull request #26 from oligot/no-context

Use execution_variable instead of context
Removed useless dependencies on other lib.
Added `append_string_to' to HTTP_HEADER
Removed eel and eapml contrib/library from EWF
Since there are available from $ISE_LIBRARY
using ARRAYED_LIST rather than LINKED_LIST
Added HTTP_DATE to ease http date manipulation and optimize code rather than using EiffelTime's code facilities.
Added autotests to `http' lib.
Fixed HTTP_DATE for GMT+  offset  (integer value)
Added ANSI C date time string format support in HTTP_DATE.
Updated CMS code.
Separated code to have a lib and an example.
Improved design, fixed a few issues related to folder location.

This is still experimental and require more work to be really friendly to use.
Fixing global EWF compilation
Fixing global EWF compilation