I’m not great with the console, is that the PROPERTIES?
On another note. I set up a simple page, literally a CFLOCATION to a page with a drop of text and it works, but the other CFLOCATION on the other page, very odd. I tried changing the location of the file, such as not jumping from one directory to another, staying on the same page, but still the same issue.
You need to find out, what is happening in detail. In Chrome press F12 to open “chrome dev tool”, then click the “network” tab. You may need to tick the “preserve history” option. Clear the history and do a reload of the page that has the issue. Then click on the page that was loaded, and you will see all client data sent and the servers response data.
Can you also try accessing your app directly through port 8888 to see if the issue is persisting there too?
Does this help?
Access-Control-Allow-Origin:
*
Cache-Control:
private
Content-Encoding:
gzip
Content-Length:
184
Content-Type:
text/html
Date:
Sun, 10 Sep 2023 12:01:32 GMT
Strict-Transport-Security:
max-age=31536000; includesubdomains
Vary:
Accept-Encoding
X-Aspnet-Version:
4.0.30319
X-Content-Type-Options:
nosniff
X-Frame-Options:
SAMEORIGIN
X-Powered-By:
X-Xss-Protection:
1;mode=block
Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.7
Accept-Encoding:
gzip, deflate
Accept-Language:
en-GB,en-US;q=0.9,en;q=0.8
Cache-Control:
max-age=0
Connection:
keep-alive
Content-Length:
57
Content-Type:
application/x-www-form-urlencoded
Host:
dailymessage.com
Origin:
http://dailymessage.com
Referer:
Upgrade-Insecure-Requests:
1
User-Agent:
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.0.0 Safari/537.36
Have you also tried accessing the app though port 8888 to see if the issue happens also there (to isolate an IIS issue from Tomcat)?
I’m also missing the 'Location:" header in your request. Have you set the preserve log? See: debugging - How to enable "Preserve Log" in Network tab in Chrome developer tools by default? - Stack Overflow
Important: please mask the cookie header when you post it here.
I’m having trouble getting it to respond using port 8888.
I found the preserve log issue, tried the page again and it looks like I have the same info (cookies removed from this and the above)
Access-Control-Allow-Origin:
*
Cache-Control:
private
Content-Encoding:
gzip
Content-Length:
184
Content-Type:
text/html
Date:
Mon, 11 Sep 2023 06:56:08 GMT
Strict-Transport-Security:
max-age=31536000; includesubdomains
Vary:
Accept-Encoding
X-Aspnet-Version:
4.0.30319
X-Content-Type-Options:
nosniff
X-Frame-Options:
SAMEORIGIN
X-Powered-By:
X-Xss-Protection:
1;mode=block
Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.7
Accept-Encoding:
gzip, deflate
Accept-Language:
en-GB,en-US;q=0.9,en;q=0.8
Cache-Control:
max-age=0
Connection:
keep-alive
Content-Length:
57
Content-Type:
application/x-www-form-urlencoded
Host:
dailymessage.com
Origin:
http://dailymessage.com
Referer:
Upgrade-Insecure-Requests:
1
User-Agent:
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.0.0 Safari/537.36
You should be able to access it on port 8888 locally from the server. Can’t you?
Ah, it’s working on the server using the domain, but not externally, which I thought it would as I opened the port on the firewall
The result was
www.dailymessage.com is currently unable to handle this request.
HTTP ERROR 500
When I go to browse your site, its not SSL enabled (SECURE)
my suggestion as its just easier is either apache or nginx, as both are comercially adopted, both work flawlessly with lucee and both are opensource (free)
The domain I am using is just a spare domain that is not in use. I just wanted to take code from another site Kigso.com and use it on that domain so I could easily test it out of production, which is why there is on SSL on it.
Unfortunately I’m not familiar with Apache or nginx and time is rather limited so I just don’t have the time to get into those. I was hoping the migration from ACF to Lucee was going to be reasonably straight forward, but for me it’s not gone that way
After a little experimenting I have found a couple of things
a) It throws the OBJECT MOVED message on CFLOCATION, however if I change it to a META REFRESH I can get it to go to the next page
b) With the delay in the META REFRESH, I was able to check cookies on the log in page that creates them, and the receiving page where they are redirected to. The cookies are created, however when it redirects to the next page, the cookies no longer exist.
I think I’m going to give up on this install 
Perhaps return when the next version is out. I just can’t get it to work
You can give up if you like, but I would first test this directly using lucee. The sessions setting in your application.cfc or lucee admin is where you want to start.
Saying it doesn’t work like AFC, you are correct its faster, cleaner, and doesn’t have the technical clutter AFC has.
So if you want to post your error logs, and snippet into your application settings, plenty of people on here have successfully moved from AFC to lucee and can provide feedback into helping you migrate.
I would certainly like to get this going and I don’t dispute all of the benefits of moving from AFC, but I am somewhat stuck
I just cleared the log, restarted Lucee and captured the new log. To create the error in there, I logged into the web site, which creates cookies (quite a lot of them) and then the page it redirects to throws and error.
As above, if I use a CFLOCATION I get the OBJECT MOVED error, but if I use a META REFRESH I actually get an error.
The error is that a cookie.gametoken is missing (as are all the cookies it creates), however I output them on the page that performs the redirect and I can see that the cookie does indeed exist, but it does not find its way to the next page.
I can’t see any way to attach a file, so I’ve pasted the log below. Thanks to everybody for their help.
The log is too large to paste into these comments and I can’t find a way to attach a file, so I’ve pasted what I believe is likely the relevant entry →
21-Sep-2023 10:06:57.831 SEVERE [ajp-nio-127.0.0.1-8009-exec-3] org.apache.coyote.ajp.AjpMessage.checkOverflow Overflow error for buffer adding [75] bytes at position [8192]
pasteBin is useful.
Lets start with the most basic parts of this
after your application does your login, whats the code: You can create a CFTRY or pastebin example.
What is your host os
where is the file its mapped to?
where is the actual file in your file system in relation to your .cfc/m call to cflocation?
Are you using session.cookies or java session cookies or client cookies?
How are you handling sessions in general?
what are your session settings and timeout values?
If you do a cfdump of your entire scope before and after the Cflocation call, what are the differences?
The cookies are created, however when it redirects to the next page, the cookies no longer exist.
When losing cookies, its mostly because you
Maybe this will give you a hint for troubleshooting. I would guess its a configuration problem and not a problem with the code itself.
Let me answer both replies
With regards to the domain switching, in the actual site where the code came from kigso.com yes, there is some domain switching, as in it has to run across subdomains … eu.kigso.com , na.kigso.com for example, and cookies need to be read, therefore I did create cookies with domain = “.kigso.com”. I had changed this to dailymessage.com (the spare domain I am using purely for test purposes on a test VM clone server with Lucee), I have now removed all of the domain=“.dailymessage.com” from the creation of the cookies, as I don’t need it to just get this part working, it made no difference.
I changed the meta-refresh so I could dump some data before it moved to the next page.
All of the cookies are there (there are a lot of them 69 in total)
The log in is on
dailymessage.com/account/login.cfm
it redirects to
dailymessage.com/games/index.cfm
When it redirects to the games/index.cfm, all of the cookies are gone, there are none
These are client side cookies.
I’ve also tried, both yes and no in the below, just for the heck of it.
<cfapplication sessionmanagement=“yes” name=“myapp” sessionTimeout=“#createTimeSpan(0,6,0,0)#” />
With regards to HTTP vs HTTPS, as this is just for testing for myself, it’s on HTTP only, there is no switching to HTTPS
To add to the above, I moved the log in CFM to the same directory that it would redirect to, cookies still not retained.
I ran a little test, by clearing the cache and then creating a number of cookies that contained a UUID. Up to 88 cookies, everything was fine, however after that I started getting the OBJECT MOVED error.
I did actually get it earlier around 39 cookies I think it was, before I cleared the cache so there must have been other cookies sat around from previous tests.
I then cleared the cache and ran it with a value of 1 rather than the larger UUID, and found I could create more cookies.
So this is related to the header size maxing out. I have been unsuccessful in changing this.
I can confirm that this code is working fine with all of these cookies on the server that I used as a clone for this test, the only difference being the other server is using ACF 2016. The IIS settings are the same.
Test code attached
displaycookie.cfm (150 Bytes)
index.cfm (181 Bytes)
Thats a Tomcat problem with the header-size.
You can adjust the size by setting e.g. maxHttpHeaderSize="65536" in the connector node in the server.xml.
Example from the lucee-express version:
<Connector port="8888" protocol="HTTP/1.1" connectionTimeout="20000" maxHttpHeaderSize="65536" redirectPort="8443" />
Anyway you should may also consider removing the cookies (maybe move into a session?).
That cookies are send on every request, so that looks like a bit of unnecessary traffic.
For this particular test I’m using an unused domain with cloned code so there is no SLL on it.
This was actually mentioned to me by @andreas . He also mentioned
“Then change the AJP Boncode PacketSize in the Boncode Settings (see BonCode Apache Tomcat AJP 1.3 Connector). Make sure to change the correct setting file (not in the installation folder, but in the windows/ folder).”
It’s been several years but now I’m starting to question myself and whether I did indeed have an issue with the headers (number of cookies previously) and once I applied an SSL to the site it work, but I could be imagining it, it’s been a while.
Looking at the server.xml I am a little concerned I’ll mess it up/not resolve the issue as there are a few references to 8443.
With that being said, I’m thinking that perhaps my next move should be to purchase an SSL certificate and put in on the site (not that I need it, but I’ve got another domain I will need it on in the future, so I can switch things around a little).