I'm encrypting a file using AES-256 in CBC mode. I'm padding to the 16-byte input multiple by using the PKCS#7 limit. The problem I'm currently having is that if I'm transferring or reading the encrypted file over a socket, I won't know when the encrypted file has been finished, as I'm reading it in chunks. Because of this, I won't know when to trim the PKCS#7 padding from the decrypted file chunks. (I won't know the size of the decrypted data in advance, so I won't know where to look for padded bytes and to trim them.)
One solution I've thought of would be to include the unencrypted file size in the header of the encrypted file, but I'm not sure if this is a security threat or not. Is this a bad idea?
Edit
I have kind of a strange setup. Encrypted data is stored like so:
$$s \longrightarrow e_{m} \longrightarrow d$$
The source data $s$ is passed to $e_{m}$, the encryption method, over a socket. As $e$ encrypts the data, it simultaneously writes the data over another socket to the destination $d$.
Retrieval works in the inverse:
$$d \longleftarrow d_{m} \longleftarrow s$$
The encrypted source $s$ is passed through the decryption method $d_{m}$, which decrypts it and passes the decrypted data to destination $d$.
With this in mind, how can I maintain padding with AES? The contents being transferred are files, so they are inherently and usually larger than 50 bytes of data. The problem seems to be $e_{m}$ and $d_{m}$ not knowing the size of the input data and simply encrypting block-by-block.
How can I create a decryption method which, not knowing the size of $s$, will still be able to decrypt the data and send it to $d$?