Buenos Dias Sean, >1. In looking at the current DiskMultipartRequestHandler I can't tell > whether or not the request that is handed and parsed by the > MulitpartIterator is already uploaded and complete or is still > maybe uploading. Since it is reading a stream I assume that the > request may not be complete yet. Is this correct? Use case, user > wants to upload a 10MB file. This posting of that file kicks off > a MultipartRequestHandler of some kind ... is that file already > 100% ready when it gets to that point or is it still uploading?
MultipartIterator does all the work of parsing the multipart/form-data representing a file upload with form elements. Each time you call on getNextElement(), it reads a little more from the stream. When getNextElement() returns null, you've reached the end of the stream. >2. My thought process would be to modify the handleRequest method in > the DiskMultipartRequestHandler to create some > CustomMultipartIterator who's createLocalFile method (if I were to > name it simular to the current iterator) would instead of creating a > local file open a connection to that other server and begin > transfering the bytes as they are read in. Anyone see any holes in > this? You might just want to implement the MultipartRequestHandler interface instead of extending DiskMultipartRequestHandler, there doesn't seem to be much functionality in the DiskMultipartRequestHandler that you need. I don't see much gain from extending MultipartIterator, as currently it's pretty File-centric. I'll keep this in mind when I go to recode some of it, but for the time being, it looks like you might be writing your own class to parse the multipart/form-data request body. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
