Has anyone seen any CORS related issues between Lucee 5.3.9.141 and 5.3.9.160? Running a javascript app on my local dev machine connecting to a local Lucee server (Commandbox) I am seeing random CORS errors when making requests (Taffy API). I can hit the same api endpoint 5 times and 1 out of the 5 will return a CORS error when on Lucee 5.3.9.160. If I simply stop the server and then start again with Lucee 5.3.9.141 no more CORS errors. It is happening intermittently on most of my API endpoints. I recently deployed the API to AWS with Lucee 5.3.9.160 and started seeing the same random CORS errors - reverted back to 5.3.9.141 and they are gone. The only change I am making is between Lucee version .141 to .160.

what do the errors look like?

Standard Chrome CORS error in the browser console. The GET request shows no CORS related headers - it could be a red herring and there is another error. Let me try and get a simple reproducible test setup just on the api end point and see if I get a different error.

reviewing commits....

Will do

what changes in the headers again?

Nothing - the options request returns a 200 with the headers above. Then randomly the GET request will fail.

request headers look the same?

Yep, request headers are same for each request of the specific resources.

try setting env var lucee.request.limit.concurrent.maxnormprio = 0

Sorry, where do I need to set those?

the code in question reduces the priority of threads when there are too many requests from a single user

There are lots of requests coming in to load a particular section. For example the settings section makes 10 (yes 10!) separate xhr requests to different endpoints

anything in your log files?

Yes I use that on other servers - our api has lucee admin disabled by default.

cool

Will have to do some more digging tomorrow.

but the http response is the same?

Return eldest child back to Uni tomorrow and packing help is needed!

ok I understand

I'd find out what's setting the headers. I'm guessing it's Taffy based on the

x-time

headers. I suspect the issue is Taffy is setting the headers and then those changes are being reset. It might be related to how Taffy is setting the headers, or perhaps a change of behavior in Lucee.

i wanna know what the response shows? there's a 500 error

The 500 error has an empty response as far as I can tell. I have to leave it for this evening. I’ll try and create a standalone test that makes several simultaneous requests to the API and switch on Lucee admin to log it all.

Nothing in exception.log?

I've posted an answer to the lucee community forum. Pretty sure the problem is comming because of the port 8080. Domain origin must match including port. You need to find out why the port 8080 and the ommited 443 port is changing.

@Andreas that would be the case if it was happening in all versions of Lucee that I have tried and for every request. However it happens intermittently on different requests whilst working for other similar requests. Also, I was seeing the problem on our production version. As soon is I reverted back to previous version of Lucee the errors were gone.

Yeah, I see now.

if there's a 500 error, there's must be a strack trace

The problem I have at the moment is that hitting the taffy api endpoints directly - one at a time doesn’t seem to trigger the 500. It only happens intermittently from the backboneJS application that makes a number of simultaneous fetch calls to several different endpoints. So, for example the settings section of the app calls the following endpoints: • /organisations • /users • /changelog • /plans • /billing • /banners • … Then only 1 of the above will throw the 500 error - but not every time.

are you on tomcat or commandbox/undertow?

This is on commandbox/undertow but I also saw the same errors when I deployed onto our AWS Elastic Beanstalk which is running on tomcat.

good to know

I wonder if it is related to the number of calls to the api the app is making in quick succession.

that's what the code in question for that version where it starts to occur relates to

I don’t know whether it is a native 500 or taffy 500 as there is only an empty response from the endpoint.

anything in the

server.out.txt

from commandbox?

OK, just running through some checks to rule out user error (my bad code!) - I just ran the server with trace and console and debug flags so that I see loads of info in the console as I make the requests. After 3 loads of the /settings section in the app 1 of the api endpoints gave a 500 error. The other endpoints in that ‘set’ all return normally. I notice that the tuckey rewrite filters had this for the modules section:

org.tuckey.web.filters.urlrewrite.SetAttribute: set Set response-header Access-Control-Allow-Origin null called
[DEBUG] org.tuckey.web.filters.urlrewrite.SetAttribute: setting response header
[DEBUG] org.tuckey.web.filters.urlrewrite.SetAttribute: set Set response-header Access-Control-Allow-Methods null called
[DEBUG] org.tuckey.web.filters.urlrewrite.SetAttribute: setting response header
[DEBUG] org.tuckey.web.filters.urlrewrite.SetAttribute: set Set response-header Access-Control-Allow-Headers null called
[DEBUG] org.tuckey.web.filters.urlrewrite.SetAttribute: setting response header
[DEBUG] org.tuckey.web.filters.urlrewrite.SetAttribute: set Set response-header Access-Control-Allow-Credentials null called
[DEBUG] org.tuckey.web.filters.urlrewrite.SetAttribute: setting response header

In fact, that is happening on all of the api endpoints. Here’s the tuckey rule set for CORS:

<rule>
		<note>
		  <http://enable-cors.org>
		</note>
		<condition type="header" name="Origin">.*</condition>
		<condition type="header" name="Access-Control-Request-Method">.*</condition>
		<condition type="header" name="Access-Control-Request-Headers">.*</condition>
		<set type="response-header" name="Access-Control-Allow-Origin"></set>
		<set type="response-header" name="Access-Control-Allow-Methods"></set>
		<set type="response-header" name="Access-Control-Allow-Headers"></set>
		<set type="response-header" name="Access-Control-Allow-Credentials"></set>
	</rule>

Setting blank responses seems a little odd - should those empty headers contain ‘*’?

thanks for the update, so there were no exceptions in any of the logs?

Nope - all very odd!

no, I reckon, it's definately something on the lucee side

It does seem odd that it happens for lucee@5.3.9-SNAPSHOT+151 onwards and not previous versions. And my app may be unusual in that it is making multiple simultaneous fetch requests to different endpoints in the API. I’m a bit swamped at the moment on another project but will be back on this in the next few days. I’ll try and build a simple index.htm page with a bunch of fetch calls to the api and see if I can try and replicate the issue - and get some log data etc.

Was postman threaded and using sessions?

Good question - not sure how I can see that in Postman.

you'd need to do a login and then pass in the session cookies for subsequent requests

cfm session cookies? Our API is stateless - no cookies

ok

We pass an authorization header from the backbone app for each fetch request. The authorization header contains a unique user token which then returns the correct data for that user.