Hi folks,
I guess the following will come as a surprise to some:
Could the NLS download problem be related to dynamic URL/PATH
generation?
Some websites use dynamic URL generation to show specific pages.
This could include page ID number for an article, pages shown to
a site member and download links for some catalogs. When these
pages are encountered, the address of the site becomes something
like:
http://myexample.com/somename.cgi?id=num
Where "somename" is the name of some script file and the id
refers to the ID number associated with the generated page. For
instance, the download links for NLS books have the following URL
format:
https://nlsbard.loc.gov/cgi-bin/nlsbardprod/downloadbook.cgi?book
=id
Where ID is the "NLS BARD site's" link ID for the actual zip
book. In other words, the number that follows the last equals
sign refers not to the actual DB book number, but the ID within
the BARD's site database that refers to the "real" link to the
zip file (which could be somewhere on the web server). From what
I found, Internet Explorer 8 (on my PC) can "retrieve and
download" the "real" book based on the CGI script, but Apex (and
presumably mobile browsers) can't; if file download is attempted,
KeyWeb gives the wrong file name - not the zip file, but the CGI
name and the ID from that script, reading
to download failure.
As a support material, as it was said a while ago, our hypothesis
on how KeyWeb gets file download information could be applied in
NLS situation: that the file size is based on KeySoft "possibly"
querying the web server for the file size, and this method works
IF AND ONLY IF file path is statici.e. doesn't change as a
result of scripts or other programs running on the server. Since
NLS uses scripts to generate book ID's and tells the web browser
where to retrieve the actual file, KeyWeb would have harder time
getting to the "real" file, giving rise to the phenomenon where
BrailleNote treats last parts of dynamically generated URL as the
"actual file name," hence attempting to download the "address"
not the content. And this problem of "dynamically generated
URL's" and parsing issue is something that could plague some
users (mostly conversion site users), as some sites use
dynamically generated addresses and other techniques to allow web
browsers (including KeyWeb) to retrieve (in our case, attempt to
retrieve) the actual content.
#h3ee3ae p4m4 And I dare not go into possible routes that could
work for overcoming this problem for a number of reasons (two of
them being I don't work for HW so don't know KeySoft code and
second being possible complications that could arise when fixing
it).
Are there anyone else who has better words or explanations? Then
please let us know your opinions. Thanks.
Cheers,
Joseph
___
Replies to this message will go directly to the sender.
If your reply would be useful to the list, please send a
copy to the list as well.
To leave the BrailleNote list, send a blank message to
[email protected]
To view the list archives or change your preferences, visit
http://list.humanware.com/mailman/listinfo/braillenote
