HTTP Options request (netty-http, netty4-http)

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

HTTP Options request (netty-http, netty4-http)

Charles Moulliard-2
Hi,

I think that the logic of this test is wrong (
https://github.com/apache/camel/blob/master/components/camel-netty4-http/src/main/java/org/apache/camel/component/netty4/http/handlers/HttpServerChannelHandler.java#L95)
as we will only pass it if the isRestrictedToOptions boolean is false

That means that a HTTP request issued by curl, ... against the endpoint
will only get a response when the HttpMethodRestrict != OPTIONS.

As the goal of the HTTP options request is to get a Response Code 200 and
the Allow Header with methods supported (required by example by Swagger Api
with  CORS), that means that we can't use REST DSL

           rest("/").id("rest-options")
             .verb("options","/blog/article")
             .route()
             ...


as the endpoint will be defined with httpMethodRestrict=OPTIONS

[         Blueprint Extender: 3] BlueprintCamelContext          INFO
 Route: route1 started and consuming from: Endpoint[
http://0.0.0.0:9191/blog/article?httpMethodRestrict=OPTIONS]


Is me reasoning correct

Regards,

--
Charles Moulliard
Apache Committer / Architect @RedHat
Twitter : @cmoulliard | Blog :  http://cmoulliard.github.io
Reply | Threaded
Open this post in threaded view
|

Re: HTTP Options request (netty-http, netty4-http)

Claus Ibsen-2
The options was never meant to be exposed in the rest-dsl, when it was created.

The options was for the built-in CORS support.





On Mon, Sep 14, 2015 at 9:26 PM, Charles Moulliard <[hidden email]> wrote:

> Hi,
>
> I think that the logic of this test is wrong (
> https://github.com/apache/camel/blob/master/components/camel-netty4-http/src/main/java/org/apache/camel/component/netty4/http/handlers/HttpServerChannelHandler.java#L95)
> as we will only pass it if the isRestrictedToOptions boolean is false
>
> That means that a HTTP request issued by curl, ... against the endpoint
> will only get a response when the HttpMethodRestrict != OPTIONS.
>
> As the goal of the HTTP options request is to get a Response Code 200 and
> the Allow Header with methods supported (required by example by Swagger Api
> with  CORS), that means that we can't use REST DSL
>
>            rest("/").id("rest-options")
>              .verb("options","/blog/article")
>              .route()
>              ...
>
>
> as the endpoint will be defined with httpMethodRestrict=OPTIONS
>
> [         Blueprint Extender: 3] BlueprintCamelContext          INFO
>  Route: route1 started and consuming from: Endpoint[
> http://0.0.0.0:9191/blog/article?httpMethodRestrict=OPTIONS]
>
>
> Is me reasoning correct
>
> Regards,
>
> --
> Charles Moulliard
> Apache Committer / Architect @RedHat
> Twitter : @cmoulliard | Blog :  http://cmoulliard.github.io



--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2nd edition:
https://www.manning.com/books/camel-in-action-second-edition
Reply | Threaded
Open this post in threaded view
|

Re: HTTP Options request (netty-http, netty4-http)

Charles Moulliard-2
Even if the goal was not with first implementations of REST DSL to expose
the OPTIONS verb within the DSL, I think that it makes sense to propose it (
https://issues.apache.org/jira/browse/CAMEL-9129) for the following reasons
:
- The browser will issue OPTIONS requests when CORS is enabled. This is
typically what will happen when the Swagger UI runs into a different HTTP
Server (8080) instead of the server running the Camel REST Endpoints
(9090).
- It could also be use to reply to applications interested to know which
operations are supported by the endpoints (
http://zacstewart.com/2012/04/14/http-options-method.html).

We have nevertheless to review the code about the jetty, netty, netty4, ...
components to be sure that they will send a correct response when an
OPTIONS operation is issued as this is not the case for the moment.


On Mon, Sep 21, 2015 at 12:59 PM, Claus Ibsen <[hidden email]> wrote:

> The options was never meant to be exposed in the rest-dsl, when it was
> created.
>
> The options was for the built-in CORS support.
>
>
>
>
>
> On Mon, Sep 14, 2015 at 9:26 PM, Charles Moulliard <[hidden email]>
> wrote:
> > Hi,
> >
> > I think that the logic of this test is wrong (
> >
> https://github.com/apache/camel/blob/master/components/camel-netty4-http/src/main/java/org/apache/camel/component/netty4/http/handlers/HttpServerChannelHandler.java#L95
> )
> > as we will only pass it if the isRestrictedToOptions boolean is false
> >
> > That means that a HTTP request issued by curl, ... against the endpoint
> > will only get a response when the HttpMethodRestrict != OPTIONS.
> >
> > As the goal of the HTTP options request is to get a Response Code 200 and
> > the Allow Header with methods supported (required by example by Swagger
> Api
> > with  CORS), that means that we can't use REST DSL
> >
> >            rest("/").id("rest-options")
> >              .verb("options","/blog/article")
> >              .route()
> >              ...
> >
> >
> > as the endpoint will be defined with httpMethodRestrict=OPTIONS
> >
> > [         Blueprint Extender: 3] BlueprintCamelContext          INFO
> >  Route: route1 started and consuming from: Endpoint[
> > http://0.0.0.0:9191/blog/article?httpMethodRestrict=OPTIONS]
> >
> >
> > Is me reasoning correct
> >
> > Regards,
> >
> > --
> > Charles Moulliard
> > Apache Committer / Architect @RedHat
> > Twitter : @cmoulliard | Blog :  http://cmoulliard.github.io
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2nd edition:
> https://www.manning.com/books/camel-in-action-second-edition
>



--
Charles Moulliard
Apache Committer / Architect @RedHat
Twitter : @cmoulliard | Blog :  http://cmoulliard.github.io