REST Method OPTIONS - ERR_EMPTY_RESPONSE

Posted by alextrs82 on 03-Mar-2015 15:56

Get an error: net::ERR_EMPTY_RESPONSE when application makes PUT request, have no problems when request is sent using Postmaster. This started to happen after we moved REST adapter to stand-alone Tomcat 7 server with messenger (it works fine on Tomcat that comes with OE). We use form-OERealm security and configured CORS to allowAll:

<b:bean id="OECORSFilter"
   class="com.progress.rest.security.OECORSFilter" >
   <b:property name="allowAll" value="true" />
</b:bean>

All Replies

Posted by Michael Jacobs on 04-Mar-2015 04:29


The 'allowAll' property definition:  "Allow generic HTTP clients access without requiring CORS headers on each request".   If the client does send CORS headers ( which is generally the case with JavaScript clients ) then the server will still do the cross-origin validation and can reject the request.    Generally the http response code gives you a clue

403  Forbidden - The CORS headers were required and not found; the client sent a header that was not allowed; client domain not allowed

400  Bad request - the client sent an invalid CORS preflight request

405  The request's method was not allowed

You can add debug logging for the com.progress.rest.security package to see details.

Mike J.

[collapse]
From: alextrs82 <bounce-alextrs82@community.progress.com>
Reply-To: "TU.OE.Development@community.progress.com" <TU.OE.Development@community.progress.com>
Date: Tuesday, March 3, 2015 at 4:57 PM
To: "TU.OE.Development@community.progress.com" <TU.OE.Development@community.progress.com>
Subject: [Technical Users - OE Development] REST Method OPTIONS - ERR_EMPTY_RESPONSE

Thread created by alextrs82

Get an error: net::ERR_EMPTY_RESPONSE when application makes PUT request, have no problems when request is sent using Postmaster. This started to happen after we moved REST adapter to stand-alone Tomcat 7 server with messenger (it works fine on Tomcat that comes with OE). We use form-OERealm security and configured CORS to allowAll:

<b:bean id="OECORSFilter"
   class="com.progress.rest.security.OECORSFilter" >
   <b:property name="allowAll" value="true" />
</b:bean>
Stop receiving emails on this subject.

Flag this post as spam/abuse.

[/collapse]

Posted by alextrs82 on 04-Mar-2015 13:34

That's the thing, it fails on OPTIONS method, Chrome shows:

OPTIONS - (failed)

                  net::ERR_EMPTY_RESPONSE

Provisional headers are shown

Access-Control-Request-Headers:accept, content-type

Access-Control-Request-Method:PUT

Origin:http://localhost:8000

Referer:http://localhost:8000/

User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.115 Safari/537.36

And GET / POST work with no problems

Posted by Michael Jacobs on 04-Mar-2015 14:33

To not spend time guessing about who's not doing what, it is probably time to go the debug logging route in the REST service.

WEB-INF/classes/log4j.properties

log4j.logger.com.progress.rest.security=DEBUG, ...

Look for the CORS class reference in the REST service's log file.

Posted by alextrs82 on 05-Mar-2015 08:15

I don't see anything related to PUT in logs (see the attachment)

Posted by alextrs82 on 05-Mar-2015 08:33

It's worth mentioning that these are INVOKE operations on AppServer side (don't know whether it makes any difference)

Posted by egarcia on 05-Mar-2015 09:15

Hello,

Just some few troubleshooting tips  in case they help.

What is the code performing the PUT request?

What object is performing the request (jQuery, the JSDO, the XMLHttpRequest object, other)?

Do you see this issue only from Google Chrome or does it also happen with other web browsers?

Do you see anything special in the Network tab or in the JavaScript Console?

Any difference between the request headers when doing your PUT request vs the request headers when using Postmaster?

Perhaps, there is a difference and it causes the server to return an empty response.

I hope this helps.

P.S:

If you were still trying to pin point where the problem was happening, a possible approach would have been to create a proxy to see the network requests.

The WSAViewer tool included in OpenEdge and Fiddler ( http://www.telerik.com/fiddler ) can be used for this.

This approach would be particularly useful if you did not have access to debugging tools to see the network interaction.

Posted by Michael Jacobs on 05-Mar-2015 10:26

Looking at the REST service's log shows a couple of things:

1) The CORS preflight (OPTIONS) request do not appear to be getting to the OE CORS handler

2) The OE CORS filter shows no indications that it is rejecting a request

Taken together, the client's CORS OPTIONS request is running into some other problem that is causing an error response.

This thread is closed