Uploading Files to a NetTalk Web Server with NT7 or later

[Bruce]

I was having an interesting conversation with Chuck, who needed to post a file up to a server. The process seemed simple enough, it's a long-standing requirement, create a form, add a File Upload field and so on, but it just didn't work.

After examining the server for a bit I realized that it's not the code which is wrong, it's the approach. The Form procedure has grown up over the years, and while it's possible to "drive" the form automatically, it's also more complicated now because a form expects to go through a number of stages. You'd have to make at least two calls, the first to generate the form, the second to do the POST while at the same time preserving the Session Cookie, and FormState value. It's do'able, but seems like a lot of work.

Fortunately there's an easier way.

If you create a NetWebPage, rather than a Form, then you can simplify things a lot, because a Page is parsed exactly like a form (so all the fields are available for you to use) and a page doesn't have the inherent "expectations" that a form has.

On the sending side, Chuck has based his sender on the example "Examples\NetTalk\WebClient\Web Client Send File\websend.app".

That contains the following code;

   net.SetValue('whatever',something)
    net.SetValue(FieldName,FileName,true)
    net.Post(URL,'')    

As you can see any number of fields can be included in the post, and disk files can be included.

On the server side, if the procedure is a NetWebPage, not a NetWebForm, then any embed code can be added to do whatever you like with the fields. The contents of the simple text fields are in

p_web.GetValue('whatever')

and the incoming files can be saved by doing

p_web.SaveFile('fieldname','name on disk')

The name of the file being sent, _including_ the path of the sender machine is in

p_web.GetValue('fieldname')

StringTheory has a method called FileNameOnly that strips off the path. So putting it all together, let's say the name of the incoming field is 'FileFromClient' then the code to save the incoming file, into a directory called c:\temp\incoming looks like this;

str  StringTheory

...

  str.SetValue(p_web.GetValue('FileFromClient'))
  str.SetValue('c:\temp\incoming\' & str.FileNameOnly())
  p_web.SaveFile('FileFromClient',str.GetValue())



Cheers
Bruce

[Wolfgang Orth]

Hello Bruce,

this post, together with the UserGroup Webinar #3 (http://www.capesoft.com/ftp/public/webinars/UG_NT003_20140116_NetTalkUserGroupMeeting3.wmv) makes it easy to write such a combo for a quick and easy file transfer. Works great!

However..... on the client-side I do not know, when the upload has completed and I also do not know for sure, whether the upload has really been complete, with no Bytes lost.

Question A) would be: where on the client-side do I find the embed to determine, thatthe upload has finished.

Question B): How to verify the integrity of the uploaded file?

I could do a check for the MD5-hash on the client-side and send it together with the file itself. But how do I get a response from the server?

Would a SOAP-combo be the better solution in this case?

The SOAP-client can send both the file as a StringTheory-object and also the MD5 as a parameter, together with many other values, if needed. The SOAP-server would then return a TRUE or FALSE or whatever. (or in paranoia mode the server returns the MD5 and the client does the comparison).

Anyway, would that be the way to go?

Thanks,
Wolfgang

[Bruce]

These days I would use a NetWebServiceMethod to do this, not a NetWebPage. It's easy to make a FILE a parameter for a NetWebServiceMethod. Either way, the answers to your questions are the same;

>> Question A) would be: where on the client-side do I find the embed to determine, thatthe upload has finished.

In the .PageRecieved method. When the upload is completed the server will do whatever it needs to do, then send a response. When you get the response you know the upload has completed.

>> Question B): How to verify the integrity of the uploaded file?

You don't need to worry about this. HTTP is an "Error free" protocol, meaning the contents of the post cannot change in transit without being detected at the networking layer. The connection can of course be broken, but then you'll not get a .PageRecieved (and ultimately the .ErrorTrap will be called with a Timeout.)

Cheers
Bruce