We have been investigating an error in our application that seems to be unique to Lucee that we had not previously seen in ACF. All values in the FORM scope are missing on occasion for a page that processes file uploads from a multipart/form-data POST.

We came across partial uploaded files in the Lucee temp directory correlated with the errors leading us to dig into the Lucee form processing code.

We have been able to reproduce a similar issue using the following steps (it is a bit convoluted, my apologies):

• Start up Fiddler, select Rules->Performance->Simulate Modem Speeds (this helps to slow things down so you can do the remainder of the steps)

• Submit an upload with a form similar to the index.html below and a 20MB file. The size isn’t too important, the larger file just gives you time to shut down fiddler.

• Exit fiddler to simulate a network exception

The behavior we are seeing is that in lucee.runtime.type.scope.FormImpl#initializeMultiPart the call to getItemIterator() is returning with an empty iterator because the network exception is swallowed by lucee.runtime.net.http.HTTPServletRequestWrap#storeEL. This causes the initializeMultiPart method to exit without setting any exception condition and an empty Form scope.

The request continues processing as if no issue had occurred but the Form scope has no values.

We played around with not suppressing the exception in storeEL(). In that case, the catch clause in initializeMultiPart will set an initException. That was better but still not ideal since the network exception is not discovered until a call to the cffile tag; references to the FORM scope are mysteriously empty until then.

I suspect the desired behavior would be to abort the request in the case of an incomplete POST because of a network exception, or to throw an exception that can be caught in CF code.

We can test for the missing FORM scope as an error condition but figured we’d share our research into the issue in case a Lucee behavior change is warranted.