How to specify end of file when sending it over ne

Question

My servlet reads from a binary file using the FileInputStream.read(). This returns -1 if end of file is reached. It then sends the bytes of the file to the client over the response stream.

I want to then send the bytes of a md5 hash of the file over the response stream. How should i split the end of file from the md5 of the file so that the client knows which bytes are which? I can't send a -1 byte because then the stream stops working.

Are there any other bytes i can send to signal end of file that i know could not possibly be inside the actual file, and so not possibly signal the end of the file before it actually ends?

Answer 1

The other answers are good - I just mention this to give you another viewpoint. You can make the MD5 hash a separate resource in your servlet namespace.

E.g. your client requests "path/download-file" to download a file, and "path/download-file.md5" to get the md5. Your code that computes the MD5 can do so while the file is being downloaded, and write to the file system, or store the hash in a cache (possibly persistent.)

In its basic form, this assumes that the client will download the file before the md5. You could put in checks to ensure this is the case. The alternative is to compute the md5 on demand, but if the client requests the md5 before the file, then you get the double-read inefficiency that you were hoping to avoid. Mandating that the md5 is requested after the file is downloaded avoids this.

Answer 2

Send the MD5 hash first since it has a known length.

Answer 3

Assuming you can rely on the file not to change, I would read the file once and compute the MD5 hash, set that as a header, and then write the file out as the complete body. That's likely to be easier for the client to handle than splitting the body into two parts.

If the file is small enough, you could write it into a ByteArrayOutputStream as you read/hash it, to avoid having to read it twice - but if the file is large, you probably don't want to take that memory hit.

Another option is to store the hash in the file system - make whatever's writing the file in the first place responsible for hashing it. That way you only need to hash it once; you could always hash it as you read it to verify the hash if necessary.