Skip to main content

Hi Unifacers,

up to last week my Uniface REST DSPs were supporting HEAD, GET, POST, PUT, DELETE methods; now I would like to extend them to TRACE and OPTIONS.

I've added those new REQUEST_METHODs to my DSP sample but trying to request them I did NOT reach the DSP, because I presume Tomcat is directly answer me.

These are responses received:

Executing request with OPTIONS method:

OUTPUT - headers:
Server=Apache-Coyote/1.1Allow=GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONSContent-Length=0Date=Sun, 18 Apr 2021 10:05:33 GMT
OUTPUT - content:
(empty)
OUTPUT - response:
HTTP/1.1 200 OK

Executing request with TRACE method:

OUTPUT - headers:
Server=Apache-Coyote/1.1Allow=HEAD, DELETE, POST, GET, OPTIONS, PUTContent-Length=0Date=Sun, 18 Apr 2021 10:05:19 GMT
OUTPUT - content:
(empty)
OUTPUT - response:
HTTP/1.1 405 Method Not Allowed

I see a sort of contradiction here: default OPTION method is telling me TRACE is allowed but if I request TRACE the answer is "405 - Method NOT Allowed". (???)

I have three questions to be answered:

Question #1: the contradiction found is a "feature"? If yes, why is it there?

Question #2: I would like in both methods to reach the DSP to generate a proper answer page. Is this approach correct? Any pitfall to be considered?

Question #3: I am NOT a great Tomcat expert; could someone point me to a documentation page or in the right direction to adapt the basic Uniface configuration to support what I would like to do?

Thanks in advance for any hint, tips or trick.

Regards,
Gianni

Hi Unifacers,

up to last week my Uniface REST DSPs were supporting HEAD, GET, POST, PUT, DELETE methods; now I would like to extend them to TRACE and OPTIONS.

I've added those new REQUEST_METHODs to my DSP sample but trying to request them I did NOT reach the DSP, because I presume Tomcat is directly answer me.

These are responses received:

Executing request with OPTIONS method:

OUTPUT - headers:
Server=Apache-Coyote/1.1Allow=GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONSContent-Length=0Date=Sun, 18 Apr 2021 10:05:33 GMT
OUTPUT - content:
(empty)
OUTPUT - response:
HTTP/1.1 200 OK

Executing request with TRACE method:

OUTPUT - headers:
Server=Apache-Coyote/1.1Allow=HEAD, DELETE, POST, GET, OPTIONS, PUTContent-Length=0Date=Sun, 18 Apr 2021 10:05:19 GMT
OUTPUT - content:
(empty)
OUTPUT - response:
HTTP/1.1 405 Method Not Allowed

I see a sort of contradiction here: default OPTION method is telling me TRACE is allowed but if I request TRACE the answer is "405 - Method NOT Allowed". (???)

I have three questions to be answered:

Question #1: the contradiction found is a "feature"? If yes, why is it there?

Question #2: I would like in both methods to reach the DSP to generate a proper answer page. Is this approach correct? Any pitfall to be considered?

Question #3: I am NOT a great Tomcat expert; could someone point me to a documentation page or in the right direction to adapt the basic Uniface configuration to support what I would like to do?

Thanks in advance for any hint, tips or trick.

Regards,
Gianni

Hi there,

find a partial answer digging into configuration:

Config param "allowTrace" for HTTP connector. Default: false.
A boolean value which can be used to enable or disable the TRACE HTTP method.

Setting it true into server.xml config file enable to accept it.

Now executing request with TRACE method is giving back:

OUTPUT - headers:
Server=Server=Apache-Coyote/1.1·;Content-Type=message/http·;Content-Length=106·;Date=Mon, 19 Apr 2021 12:39:33 GMT
OUTPUT - content:
TRACE /uniface/wrd/REST_EXAMPLE_API HTTP/1.1
user-agent: Uniface 9.7
host: localhost:8085
accept: */*
OUTPUT - response:
HTTP/1.1 200 OK

TRACE method now works...question #1 is answered, but now TRACE is still managed directly from Tomcat like OPTIONS...so questions #2 e #3 remain open.

Is it possible to manage TRACE and OPTIONS methods from within my Uniface DSP?

Let's continue to dig...waiting for an help! 🙂

Gianni


Hi Unifacers,

up to last week my Uniface REST DSPs were supporting HEAD, GET, POST, PUT, DELETE methods; now I would like to extend them to TRACE and OPTIONS.

I've added those new REQUEST_METHODs to my DSP sample but trying to request them I did NOT reach the DSP, because I presume Tomcat is directly answer me.

These are responses received:

Executing request with OPTIONS method:

OUTPUT - headers:
Server=Apache-Coyote/1.1Allow=GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONSContent-Length=0Date=Sun, 18 Apr 2021 10:05:33 GMT
OUTPUT - content:
(empty)
OUTPUT - response:
HTTP/1.1 200 OK

Executing request with TRACE method:

OUTPUT - headers:
Server=Apache-Coyote/1.1Allow=HEAD, DELETE, POST, GET, OPTIONS, PUTContent-Length=0Date=Sun, 18 Apr 2021 10:05:19 GMT
OUTPUT - content:
(empty)
OUTPUT - response:
HTTP/1.1 405 Method Not Allowed

I see a sort of contradiction here: default OPTION method is telling me TRACE is allowed but if I request TRACE the answer is "405 - Method NOT Allowed". (???)

I have three questions to be answered:

Question #1: the contradiction found is a "feature"? If yes, why is it there?

Question #2: I would like in both methods to reach the DSP to generate a proper answer page. Is this approach correct? Any pitfall to be considered?

Question #3: I am NOT a great Tomcat expert; could someone point me to a documentation page or in the right direction to adapt the basic Uniface configuration to support what I would like to do?

Thanks in advance for any hint, tips or trick.

Regards,
Gianni

Hi Gianni,

At this moment the WRD only handles the following HTTP request methods:

  • GET
  • POST
  • PUT
  • DELETE

Other request methods are currently not handled and this means that your REST DSP will not be called in these cases.

I hope this helps.

Daniel

Hi Gianni,

At this moment the WRD only handles the following HTTP request methods:

  • GET
  • POST
  • PUT
  • DELETE

Other request methods are currently not handled and this means that your REST DSP will not be called in these cases.

I hope this helps.

Daniel

Hi Daniel,

afaik current WRD is letting pass through also HEAD method. Anyhow, thanks to clarify it!

I am going to follow up with a wish on this subject.

Gianni

Hi Gianni,

At this moment the WRD only handles the following HTTP request methods:

  • GET
  • POST
  • PUT
  • DELETE

Other request methods are currently not handled and this means that your REST DSP will not be called in these cases.

I hope this helps.

Daniel

Thanks Gianni. I did not test any of this, but just peaked into the sources of the WRD. Maybe the HEAD method is handled differently? Don't know (without doing further tests).

Daniel

Hi Gianni,

At this moment the WRD only handles the following HTTP request methods:

  • GET
  • POST
  • PUT
  • DELETE

Other request methods are currently not handled and this means that your REST DSP will not be called in these cases.

I hope this helps.

Daniel

Hi Daniel,

I've done few test:
requesting HEAD method is passing through WRD and reaching my DSP...but exited informations are in a mix zone:
if any content is built into OUTPUT channel the header is containing Content-Length=XXX, where XXX is the length of informations put into OUTPUT channel, but the content itself is not reaching caller, I suppose it is NOT copied from WRD to content output.

Considering HEAD method should be used as a sort of "keepalive" action it is acceptable for time being. Anyhow I would like in perspective to have more control from the called DSP, same way as I've already requested for TRACE and OPTIONS. I'll try to describe everything in the wish.

Gianni

Hi Unifacers,

up to last week my Uniface REST DSPs were supporting HEAD, GET, POST, PUT, DELETE methods; now I would like to extend them to TRACE and OPTIONS.

I've added those new REQUEST_METHODs to my DSP sample but trying to request them I did NOT reach the DSP, because I presume Tomcat is directly answer me.

These are responses received:

Executing request with OPTIONS method:

OUTPUT - headers:
Server=Apache-Coyote/1.1Allow=GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONSContent-Length=0Date=Sun, 18 Apr 2021 10:05:33 GMT
OUTPUT - content:
(empty)
OUTPUT - response:
HTTP/1.1 200 OK

Executing request with TRACE method:

OUTPUT - headers:
Server=Apache-Coyote/1.1Allow=HEAD, DELETE, POST, GET, OPTIONS, PUTContent-Length=0Date=Sun, 18 Apr 2021 10:05:19 GMT
OUTPUT - content:
(empty)
OUTPUT - response:
HTTP/1.1 405 Method Not Allowed

I see a sort of contradiction here: default OPTION method is telling me TRACE is allowed but if I request TRACE the answer is "405 - Method NOT Allowed". (???)

I have three questions to be answered:

Question #1: the contradiction found is a "feature"? If yes, why is it there?

Question #2: I would like in both methods to reach the DSP to generate a proper answer page. Is this approach correct? Any pitfall to be considered?

Question #3: I am NOT a great Tomcat expert; could someone point me to a documentation page or in the right direction to adapt the basic Uniface configuration to support what I would like to do?

Thanks in advance for any hint, tips or trick.

Regards,
Gianni

I've opened a new wish HERE, related to this post.

Gianni

Terms & ConditionsAccessibility statement