Menu

#6 http and url handling too complex

feature request
closed-fixed
hyperref (23)
5
2003-05-13
2001-04-18
No

The handeling of urls and http/ftp/etc. protocols
should be simplified. This should fix bugs.

With regards to http urls xdvik should send a request
to the server to establish the mime-type the server
thinks the document is. If text/html, text/plain or
application/binary (common default types) is reported
back xdvik's own mime-type heuristics should be
applied. If any other type is reported xdvik should
heed it.

Xdvi should handle application/x-dvi and
application/dvi itself and hand all other types to the
assigned web browser.

Special needs in heuristics: Historicaly xdvi has had
two features people often use:
- Not having to type the .dvi extention, i.g., go 'xdvi
foo' to view foo.dvi
- Not having to use any specific filename extention on
dvi files: "xdvi foo" should pick up "foo" if it exists

This has two results:
- Filename search heuristics: foo, then foo.dvi
- xdvi's own mime-type heuristics must default to
application/dvi.

Discussion

  • Stefan Ulrich

    Stefan Ulrich - 2001-07-13
    • labels: 326184 --> hyperref
     
  • Stefan Ulrich

    Stefan Ulrich - 2002-05-05

    Logged In: YES
    user_id=177175

    Actually I'm starting to think that the entire www fetching
    by xdvik is misguided from the start. Why not just invoke a
    browser to fetch remote files? There are so many things
    broken or missing in the browsing code ... some random
    examples:

    - You can't interrupt fetching a file. I've managed to get
    status messages about a download into the statusline; next
    I wanted to implement a `stop' button for the Motif
    version. I wasn't able to find a libwww routine that
    allows for that. E.g. when I kill my modem connection
    while doing a download, xdvik will simply hang (I didn't
    wait to find out how long it would take; it was more than
    10 seconds). At that point I had to ask myself: Most
    browsers have a stop button integrated in the GUI, so why
    on earth do I need to we re-invent that wheel?

    - No handling of username/password for protected http and
    ftp sites. Libwww allows reading an ftp password, but we
    don't have GUI elements for that. A simple solution
    would conflict with the simple solution for the item
    above, namely forking another instance of xdvi to do the
    downloading and prevent freezing of the current instance;
    the forked instance can't ask for a password any more.

    - click on Thomas Esser's name in the title of TETEXDOC.dvi,
    and you'll get a popup:

    Couldn't open URL `mailto:te@informatik.uni-hannover.de':
    libwww: Fatal Error: Wrong or unknown access scheme
    (mailto)

    Of course, mailto is a no-brainer for browsers. I haven't
    even tried other schemes like https etc.

    - libwww is a buggy monster, and the maintainers don't
    respond to bug reports, so getting rid of it certainly
    wouldn't hurt either.

    I'll admit that having your own WWW fetching routines was a
    neat and geekish thing in the 90s, but I really don't see
    the point at present ;-) E.g. kdvi will (of course) use the
    browser to fetch remote documents.

    So, to sum up: I vote for disabling the www fetching stuff
    altogether. It seems an easy way to do this is just to
    return -1 at the start of fetch_relative_url as a first
    step. Then we can wait if people complain, and if they
    don't, progressively remove the underlying cruft.

    If nobody has strong arguments against this, I'll go ahead
    and do this first step in the next release of the HEAD
    branch (if there ever will be one, that is - still haven't
    gotten around to implement the hyperref fixes yet.)

     
  • Stefan Ulrich

    Stefan Ulrich - 2002-05-05

    Logged In: YES
    user_id=177175

    Just another remark on the file heuristics ... you wrote:

    > - Not having to type the .dvi extention, i.g., go 'xdvi
    > foo' to view foo.dvi

    I agree with that ...

    > - Not having to use any specific filename extention on
    > dvi files: "xdvi foo" should pick up "foo" if it exists

    ... but I don't agree on this one. `foo' shouldn't really be
    treated as a DVI file if no foo.dvi exists (I don't know of
    any DVI creator that doesn't use the .dvi extension). I
    think this is really part of the confusion about local and
    remote files: For local files, having `foo' default to
    `foo.dvi' (if such a file exists) makes perfect sense. But
    for remote files, we can of course never know whether
    `foo.dvi' exists. For these files, defaulting to
    application/x-dvi is a major problem since it prevents a
    reasonable treatment of a lot of URLs. The `mailto:' case is
    an example for this: figure_mime_type will return
    `application/x-dvi' for
    `mailto:te@informatik.uni-hannover.de', which just doesn't
    make sense. Similar for README files etc. Passing these
    things to a browser would be give much better results ;-)

    So in my view a reasonable heuristics would be:

    - for ordinary filenames, or `file:' schemes, if filename is
    `foo' or `foo.dvi': Check whether foo.dvi exists; if so,
    pass to xdvi, else pass to browser.

    - in all other cases, pass to browser.

     
  • Stefan Ulrich

    Stefan Ulrich - 2002-05-06

    Logged In: YES
    user_id=177175

    FWIW, rev. 1.49 of hypertex.c contains changes that
    implement the suggestions from above.

     
  • Stefan Ulrich

    Stefan Ulrich - 2002-05-06
    • assigned_to: nobody --> stefanulrich
    • status: open --> pending
     
  • Stefan Ulrich

    Stefan Ulrich - 2003-05-13
    • status: pending --> closed-fixed
     

Log in to post a comment.