On Fri, 10 Mar 2000, Ruediger zu Dohna wrote:
> At 9:08 Uhr -0700 09.03.2000, Scott Raney wrote:
> > > Why is a url placed in the cachedURLs whether it was actually
> >> downloaded or not, and whether the file exists or not?
> >
> >Because the engine can't tell this: the HTTP server sends some data
> >and the engine caches that. It's up to the developer to determine
> >whether or not that data is the data they wanted.
> >
> >> Why does "URLStatus" only give information about what is in the cache?
> >> The cache is wrong sometimes. Shouldn't it be tracking the download? If
> >> not, what's it for?
> >
> >The cache isn't ever "wrong", nor is the urlStatus: it just says
> >whether something has completed downloading, not whether what was
> >downloaded is what you're waiting for.
> >
> > > How can I find out whether the download actually was successful?
> >
> >Because this is an HTTP protocol issue, not a "load" command issue or
> >a "urlStatus" issue.
>
> The core of the problem is that there is no access to the http header
> replied by the server. You can set additional headers that are sent
> to the server with the httpHeaders property, but you can not read
> what the server replies back in his header. The status/error code is
> just one of the things that may be of interest, but there are many
> more (authentication, document type, proxy info, etc.)
>
> The only solution right now is to do the HTTP yourself, which is not
> very terrible, but I think built-in support would be easy to add (at
> least to the FRL):
>
> get the httpHeader of url "..."
>
> or maybe just
>
> get url "..."
> put the lastHttpHeader into ...
Just to keep you posted, the current plan is to remove the built-in
HTTP support from all of the engines in the 2.4 release and move it
out to a fully scripted implementation. New messages will be added to
allow those scripts to handle existing syntax such as 'get url
"http://whatever"'. The existing C++ implementations are very
complicated, hard to maintain, and hard to extend to add things like
you've proposed. They're also already sort of broken WRT one type of
proxy and some types of URLs (e.g., the one's with @ in them). Though
this probably precludes a property-based syntax as you've proposed, it
could easily be done with functions, as in:
get httpHeader("http://whatever")
or:
get url "http://whatever"
put lastHttpHeader() into ...
or even:
load url "http://whatever"
get getHttpHeader("http://whatever", "some header name")
It's also mean that adding support for URLs like "ftp://" and
"mailto:" will be able to use existing scripted implementations of
these protocols.
Regards,
Scott
> A lot of 2 cents can sum up ;-)
>
> Regards
> Rüdiger
> --
> ----------------------------------------------------------------------
> GINIT Technology GmbH [EMAIL PROTECTED]
> Ruediger zu Dohna
> phone: +49-721-96681-63
> Technologiepark fax: +49-721-96681-11
> Emmy-Noether-Str. 9
> D-76131 Karlsruhe www.ginit-technology.de
> ----------------------------------------------------------------------
> PGP-Fingerprint: F1 BF 9D 95 57 26 48 42 FE F8 E8 02 41 1A EE 3E
> ----------------------------------------------------------------------
>
> Archives: http://www.mail-archive.com/metacard%40lists.best.com/
> Info: http://www.xworlds.com/metacard/mailinglist.htm
> Please send bug reports to <[EMAIL PROTECTED]>, not this list.
>
********************************************************
Scott Raney [EMAIL PROTECTED] http://www.metacard.com
MetaCard: You know, there's an easier way to do that...
Archives: http://www.mail-archive.com/metacard%40lists.best.com/
Info: http://www.xworlds.com/metacard/mailinglist.htm
Please send bug reports to <[EMAIL PROTECTED]>, not this list.
