Proposal for Support CORS (Cross-Origin Resource Sharing) #216

[boillodmanuel]

Add a Filter to handle multiple resources and a Helper to add CORS headers manually.

[jlouvel]

Thanks Manuel. To move forward with this contribution, we need to take into account those aspects:

• proper mapping of the CORS headers to Java class(es) attached to the Request/Response objects (see http://restlet.com/learn/guide/2.2/core/http-headers-mapping for existing mapping)
• processing of the HTTP headers in the Restlet Engine during the overall headers parsing/formatting logic (reusing existing parsing utilities)
• for some reasons the Travis build fails with this contribution

[boillodmanuel]

I'v added headers mapping and fix GWT edition. You can review the PR.

[jlouvel]

Manuel, it looks pretty good! Just one last change before pulling this: could you replace HeaderName by a simple String for simplification purpose?

[adennie]

typo: "nae" -> "name"

[boillodmanuel]

file removed (use simple String)

[adennie]

Typically, different resources are going to support different methods (e.g. resource A might support GET/PUT, while resource B might support GET/POST). Therefore, configuring the filter with a single standard set of allowed methods doesn't seem useful to me. Instead, I suggest that you have a default behavior of allowing all methods implemented on a given resource (those annotated with @get, @put, etc), as well as a way for developers to override that on a per-request, per-resource basis. Therefore I suggest you use response.getAllowedMethods(). By default, this will be populated to reflect the annotated methods on the ServerResource, when ServerResource.options() calls updateAllowedMethods(), but a given ServerResource can modifiy that set of methods if desired in its @Options-annotated method.

[boillodmanuel]

All comments taken in account.
I add also the CorsService.
Can be merged in Milestone 4.