Well, that almost works. One small problem, since I don't know the total size of the file to be written, I can't properly set the
httpWebRequest.ContentLength
property.
Some interesting notes:
- Leave it alone. The file does not actually start transmittng until you call requestStream.Close(). This leads to huge memory consumption and usually an aborted upload (also the request times out a lot)
- 2. Set it to a large arbitrary number, say, 2GB., Exception on every write. (Out of memory)
- I am not a web protocol expert. I'm much more of a hardware/driver type guy. New to C# as well. OUCH.
Currently i am just WAGGING it at 512M for testing.
UPDATE: That does not work. I set requestStream.SendChunked to true and then data does begin to flow as it is written into the requestStream
But, always, after around 900K of data has been sent, I get the following exception:
Unable to write data to the transport connection: An existing connection was forcibly closed by the remote host.
MORE Data:
Leaving the ContentLength property at default results in :
<Response>
<ResponseCode>70121</ResponseCode>
<ErrorMessage>Invalid upload request: total bytes uploaded does not match content-length header.</ErrorMessage>
</Response>
So, it looks like there is no easy way to write or append to a file UNLESS YOU KNOW EXACTLY how much you will be writing. PERIOD.
the Update method requires a callback URL, which won't work for us. The soap.AppendFile command hangs like a big dog and the HTTP upload method won't work either.
This means that I must either cache the entire stream in memory before writing (kinda defeats the purpose), or choose another bulk data provider and tell the project manager we are up the proverbial creek, chunk a months coding efforts and start over.
This just doesn't strike me as being that hard. Why is it?