WS - File downloads, but is corrupted

[Thys]

Hi,

This is one of those cases where "it was working before, but something happened". In a file download method the file does download, but it is corrupted. The downloaded size is just a couple of bytes more than the original one. Not sure why? Here is the ServiceMethod code.

if ReturnFile.LoadFile (clip (p_web.site.UploadsPath) & '\' & clip (DocumentID)) <> 0 then
   ReturnFile.Base64Encode ()
   if FileName = '' then FileName = clip (DocumentID).
   p_web.HeaderDetails.ContentDisposition = 'attachment; filename="' & FileName & '"'
   p_web.ReplyContentType = 'application/' & ReturnFile.ExtensionOnly ()
else
   p_web.ServiceErrorQueue.ErrorNumber = 1
   p_web.ServiceErrorQueue.ErrorPosition = 'DownloadFile'
   p_web.ServiceErrorQueue.ErrorRecordId = 'DocumentID'
   p_web.ServiceErrorQueue.ErrorDescription = 'Requested file not found'
   add (p_web.ServiceErrorQueue)
end

Thys

[Bruce]

>> Here is the ServiceMethod code.

You're using a ServiceMethod, but not returning a XML or JSON payload. Rather, it appears you are returning the file as if from a simple GET request. If you are doing that, then you would need to be very sure there is no XML or JSON wrapping around the reply.

(Usually the easiest way to GET a file from the server, when doing a GET is to make a NetWebPage procedure on the server. That's what NetWebPages do. Typically Methods return some sort of formatted payload (XML or JSON) which can of course contain an encoded file. )

Cheers
Bruce

[Thys]

Thanks Bruce.

The DownloadFile and UploadFile are methods which is part of a group within the web service. For the purposes of the client applications, they need to be methods (and not just NetWebPage implementations) to that the method descriptions, SOAP and REST will work.

Because the downloaded file is slightly larger, it could be then that NT adds an XML or JSON wrapper on the response. To try to remove any wrapper, on the response parameter (of type StringTheory), I've added a blank string for the JSON and XML wrappers. I've also removed the XML Tag property of the parameter. But still no solution. Is there another property or method with which I can remove the wrapper? I tried p_web.xml = 0 and p_web.json=0 but no difference.

Thys

[Bruce]

Hi Thys,

I think you're missing the point.
Downloading files is best done with a netwebpage and needs a specific kind of header, or no header.

NetWebServiceMethods are an API methodology - not a "download file" methodology. You're trying to use one when you want to use the other.

If you want to serve a pure file from a method, then you need to very carefully edit BuildResult so you have control over the header (I suspect there shouldn't be a header at all.) But I would describe this approach as "wrong".

cheers
Bruce

[Thys]

Thanks Bruce.

I take what you say as correct that the NetWebPage is the ideal way. But there won't be a method included in a web service definition though as part of the WSDL - and there won't be a help document available as part of the web service's generated documentation. So all of the other methods (including FileUpload) will be in the web service, but only this one not. If that's the only way, then I'll have to build it that way.

Thanks
Thys

[Bruce]

Hi Thys,

If you want it to be a method, and hence part of WSDL, then you need to "wrap" what you are sending back as XML.
A method can't be described in WSDL (which implies a SOAP structure being returned) and then not return that structure.

The point being I suppose that if you want the _client_ to access this as a method, then it needs to treat it like a method. If the client wants the reply to behave like a page then it needs to call it like a page. It's not reasonable (although probably do'able) to call it like an API, but get a reply like you called a page.

Cheers
Bruce

[Thys]

Thanks again Bruce.

I changed the web method to return base64 encoded text in XML - at least to have a download method within the service. Then I added a NetWebPage method to provide a direct download mechanism. This should be good enough for now.

Thys