Any HTTP Clients handle attachments?

[Antinome]

I'm trying to interface to a document repository (Omnify)

I can't access the repository directly, but I can give an ActiveX object part numbers and revisions and get back from it an http address in the form:

http://SERVER/OmnifyWebServices/DownloadDocument.aspx?file=FILENAME.pdf

which I can put in Firefox or IE and get a pop-up window to save the attached file. I'd like that to be automatic.

Neither of the obvious tools packaged with the LV internet kit work ('URL Get Document', 'URL Get HTTP Document').

After a bit of thought that's kind of obvious. Both 'URL Get Document' and 'URL Get HTTP Document' are looking for files, not an application/octet-stream.

Any ideas?

[Phillip Brooks]

You might be able to use DataSocket to retrieve the file...

[Rolf Kalbermatter]

I'm trying to interface to a document repository (Omnify)

I can't access the repository directly, but I can give an ActiveX object part numbers and revisions and get back from it an http address in the form:

http://SERVER/Omnify...le=FILENAME.pdf

which I can put in Firefox or IE and get a pop-up window to save the attached file. I'd like that to be automatic.

Neither of the obvious tools packaged with the LV internet kit work ('URL Get Document', 'URL Get HTTP Document').

After a bit of thought that's kind of obvious. Both 'URL Get Document' and 'URL Get HTTP Document' are looking for files, not an application/octet-stream.

Any ideas?

Not exactly sure what you mean, but it should be fairly easy to modify those VIs to actually download a binary stream after they get the initial html header.

Rolf Kalbermatter

[ShaunR]

I'm trying to interface to a document repository (Omnify)

I can't access the repository directly, but I can give an ActiveX object part numbers and revisions and get back from it an http address in the form:

http://SERVER/Omnify...le=FILENAME.pdf

which I can put in Firefox or IE and get a pop-up window to save the attached file. I'd like that to be automatic.

Neither of the obvious tools packaged with the LV internet kit work ('URL Get Document', 'URL Get HTTP Document').

After a bit of thought that's kind of obvious. Both 'URL Get Document' and 'URL Get HTTP Document' are looking for files, not an application/octet-stream.

Any ideas?

The GetDocument only checks whether the type in the header is text or not. If it is text, it saves it as an ascii file. If it isn't, it saves it as a binary file. If you don't wire a path to the file terminal, it will not save anything (and won't prompt you for a filename).

[Antinome]

The GetDocument only checks whether the type in the header is text or not. If it is text, it saves it as an ascii file. If it isn't, it saves it as a binary file. If you don't wire a path to the file terminal, it will not save anything (and won't prompt you for a filename).

Yeah, that works. Misunderstanding on my part on how this VI works. I expected to see to binary data in the content output which I could dump to a binary file and a TRUE on the success output even if I didn't wire in a file. Then I tried wiring in a path to save the file but not a complete path+filename assuming it would use the same name. Even with a complete path+filename I still see no content and success=FALSE even though the file is saving correctly. I can live with that.

FWIW, this 3rd party http client does behave a lot more like I expected. I'll use the toolkit solution anyway, to minimize dependencies.

Thanks all.

Will Peterson

[ShaunR]

Yeah, that works. Misunderstanding on my part on how this VI works. I expected to see to binary data in the content output which I could dump to a binary file and a TRUE on the success output even if I didn't wire in a file. Then I tried wiring in a path to save the file but not a complete path+filename assuming it would use the same name. Even with a complete path+filename I still see no content and success=FALSE even though the file is saving correctly. I can live with that.

FWIW, this 3rd party http client does behave a lot more like I expected. I'll use the toolkit solution anyway, to minimize dependencies.

Thanks all.

Will Peterson

I agree. It has some unintuitive behaviour. It also has a couple of bugs. There's also MGI which is based on the WinInet.