link delivers a response which is a zip file stream (NodeDeleter.zip).
oe gets the data fine and stores it to file named by URL. Problem is that the content type and file name are not being set when it is served back up from loopback so depending on the link translation settings , the resultant download file via OE is named download or the url query string when it should be NodeDeleter.zip
of course, if i know the filename, i can use it in the save dialog box, but that doesn`t resemble a feature to me. lol.
puhleeze give this a look-see.
> Best regards,
> Oleg Chernavin
> MP Staff
Oleg, thanks for the reply but I think that your answer does not address the problem stated.
When I export, the file is present on the drive, still with the dynamic url stated above, but the download link js returns nothing. (in the OE app i get a stream named that is named `download` regardless of the file)
Can I suggest that you use the URL given below in OE and then export so that you might see the unique problem posed by this particular site`s technique? The download link is "EZ File Peeker" with a little drive icon.
Oh my! you do get todays award for the best worldwide customer support. Whenever is convienent for you. If a release is not too far off i can wait.
Oleg, the URL
is simply a query string, as i am sure are aware, that prompts the server to return the file "ez file peeker.zip", not "Download.aspx?SampleGuid=0221245A-CF5E-436F-BA24-EFD66C2E7512.zip"
the filename and contenttype are all in the http headers, no? that is probably where you should get the filename. to illustrate, while in OE, on the imported download page, click the link button and notice that the download box indicates `download` for filename and null for filetype. then, outside of OE, paste the url for the file
in any browser and notice the download box indicates,`ez file peeker.zip`, archive as filetype etc.
and while "Download.aspx?SampleGuid=0221245A-CF5E-436F-BA24-EFD66C2E7512.zip" is better than no zip, in OE the link only delivers "download" as a filename with no filetype and as an export, the js link does nothing.
it is details such as these that make a good product even better. ;-)
> > Oleg.
this sounds like a link translation issue.
the url is the tool to retrieve the object. the object is the focus. if the uri contained in the reponse headers differs from the request uri, the link should be changed/translated to allow the object to be stored on disk properly, no? The user wants the file and could not care less about an href whose sole purpose is to fetch the file. this is all assuming the case of offline translation.
just my $.02. ;-)