You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Charles Moulliard <ch...@gmail.com> on 2015/09/14 21:26:34 UTC
HTTP Options request (netty-http, netty4-http)
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
Re: HTTP Options request (netty-http, netty4-http)
Posted by Charles Moulliard <ch...@gmail.com>.
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 <cl...@gmail.com> 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 <ch...@gmail.com>
> 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
Re: HTTP Options request (netty-http, netty4-http)
Posted by Claus Ibsen <cl...@gmail.com>.
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 <ch...@gmail.com> 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