Odd CFCONTENT behaviour since upgrade from 6.0 to 6.1

dev
1

We have a site that generates AWS S3 signed URLs, and then returns them via <cfcontent file="#u#" type="application/pdf" />

If I use any other random HTTPS url, such as <cfcontent file="https://falkensweb.com/" /> then I get HTML shown in the browser as expected. So connection to the internet, and fetching content is working fine.

But our code has started returning file or directory [https:XXXXXXX...] does not exist.

I’ve added

<cfhttp url="#u#"/>
<cfdump var="#u#"/>
<cfdump var="#cfhttp#"/>

by way of debugging, and this reports a “200 OK” and responseheader[‘Content-Length’] is 7629903. filecontent is a native byte array as expected.

Likewise, copy and pasting the URL to the browser works fine.

So does <CFLOCATION url="#u#"/> though this reveals the S3 URL.

The URLs that don’t work have a pattern like (removed confidential stuff) https://something.s3.eu-west-1.amazonaws.com/files/D/DD/DDDDDD.pdf?X-Amz-Security-Token=XXXXXXXX&X-Amz-Date=20250307T141930Z&X-Amz-SignedHeaders=host&X-Amz-Credential=XXXXXXXXXXXX&X-Amz-Expires=604800&X-Amz-Signature=XXXXXXXXXXX

Has anyone got any ideas what could have changed ? The release notes ( Breaking Changes Between Lucee 6.0 and 6.1 :: Lucee Documentation ) only talk about sites that return 403, and that doesn’t apply, because CFHTTP proves it’s an OK response for the exact same string CFCONTENT claims doesn’t work.

2

what does fileRead(u) do?

could be related to

https://luceeserver.atlassian.net/browse/LDEV-3947

3

fileread(u) also fails, though the resource is 200 OK

<cfhttp url="#u#" method="head"/> also fails, so maybe it is related to that, as AWS signed S3 URLs will only support one HTTP method (e.g. GET)

Is Lucee trying to be too clever here ?

4

While you guys dig into consideration of the engine and the change in versions, can you confirm what happens, Tom, if you change your test of “any other random https url” in cfcontent to be a request for a pdf, to better match the failing one? So <cfcontent file="https://falkensweb.com/some.pdf" />? I’m writing from a phone so can’t easily test this instead of asking.

5

This approach is using a resource provider url, which always does an exists check aka a HEAD request before doing a GET

it’s a common pattern in cfml, can’t remember why @micstriit knows.

I’d just do the cfhttp request to save the file locally and then cfcontent delete=true that file (which is what is happening under the hood anyway) but is faster due to no HEAD request

6

Yeah, that’s a good idea for a workaround

7

Maybe Lucee should fall back to just (single) GET if the HEAD is 403, and only fail if the GET is also 403 ?

8

could be related to https://luceeserver.atlassian.net/browse/LDEV-3947

I’ve commented there and opened https://luceeserver.atlassian.net/browse/LDEV-5387 based on discussions.