Turns out that, with Struts 1.1. at least, this can be a bad thing to do. Why? You lose the parameters on the request.
Some background: when you specify a certain encoding type for HTML forms (multipart/form-data),4 Struts turns this into a type of request called the MultipartRequestWrapper. This is done because the container implementations don't do a very good job of doing it themselves, I guess (WebLogic's certainly doesn't seem to). This wrapper class parses the request stream manually to create the parameter map.
Anyhow, this object, as I said, reads data from the input stream (well, it pushes it down to the commons-fileupload component). All is well and good, provided you don't need to forward the request on.
Why is that, I hear you ask? Well, it's simple: after you've read from the request stream once, it's at the end, isn't it? Reading from it again simply results in no data being available.
The good news, at least, is that the attributes of the request are preserved, so you can use the associated ActionForm with the action (assuming it's an action that you've forwarded to, etc, etc). Depending on the context, this may be fine, or highly distasteful (it was midly distasteful for me).
Another alternative, however, is to mark the position of the request input stream when processing a multi-part request, and then reset the stream afterwards. With a custom request processor, this is easy to do; the processMultiByte and doForward methods give you a good hook. However, this is potentially a performance problem; the request stream data will be kept in memory the whole time the request is being processed (rather than being read and discarded). (While I did this solution as part of exploring the problem, I'm going to go back to using the action form...)
----
4 This is done, for example, when you want to upload a file. In fact, uploading files is probably at least 99% of the use cases around multipart form data.
