Commit 665772bda2 forces to display only
suggestion for the request's method (this was not the case before).
This commit allows to configure this behaviour: it keeps the current behaviour
but also allows to use the other behaviour where the suggestion is displayed
for each request method (as it was before).
According to the specification, the value of the response header
Access-Control-Allow-Headers must contain at least all the values of the
request header Access-Control-Request-Headers to be considered a valid request.
Before this commit, only the Authorization value was present, which is enough
for Firefox but not for Chrome.
This should now work as expected.
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.
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
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
The logging filter is now part of EWF core (before it was only available in
the filter example) and can therefore be reused by others needing it.
Note that this is a first implementation. It can certainly be improved in
the future to support more fine grained logging.
The logging filter is now part of EWF core (before it was only available in
the filter example) and can therefore be reused by others needing it.
Note that this is a first implementation. It can certainly be improved in
the future to support more fine grained logging.
Filters are part of a filter chain, thus following the chain of responsability
design pattern.
More information are available in library/server/wsf/src/filter/README.md
Olivier Ligot
