Re: LYNX-DEV BUG? Problem with suggested name for downloaded

[Foteos Macrides]

WWW server manager <address@hidden> wrote:
>Foteos Macrides wrote:
>> 
>> WWW server manager <address@hidden> wrote:
>> >Using lynx 2.7.1 + fotemods.zip dated 21 Sep 1997, on Sun Solaris 2.5.1
>> >(SPARC) with Sun's C compiler ...
>> >
>> >Fetching compressed tar files (xxx.tar.Z) from web servers (i.e. HTTP not 
>> >FTP) by selecting the relevant links explicitly using the d(ownload) command
>> >in lynx seems to behave oddly, and certainly differently from older versions
>> >of lynx (though I don't know when it changed).
>> >
>> >Where there is a well-defined filename available from the URL, I would 
>> >expect lynx to offer that as the default for saving downloaded files (and
>> >that's what happened with the older versions I've used), but with the
>> >version described above it sometimes omits the compression suffix (for .Z, I
>> >presume .gz would be treated similarly), although the file *is* saved in
>> >in its original form. With e.g. lynx 2.4.1, the name from the URL is used
>> >unaltered.
>> > ...
>> 
>>      The HTCheckFnameForCompression() function which I added in
>> GridText.c based on discussions about Content-Disposition header
>> handling in the IETF's HTTP-WG had a bug such that it wasn't taking
>> a Content-Type of application/octet-stream into account.  That's
>> fixed in the fotemods.zip I just updated at slcc.  As Klaus has
>> reported and is discussing, he added that function to the devel
>> code.  However, he changed it's logic in ways I don't intent to
>> reproduce in the fotemods (i.e., the Lynx code that I actually
>> use seriously), so keep those discussions distinct from ones about
>> the fotemods.  Here's how it's intended to work in the fotemods.
>> If it doesn't, continue reporting bugs via the lynx-dev list.
>
>Thank you for the fix and the explanation.
>
>One followup question ... I'm now confused - I'd got the impression that the
>updates collected together in successive fotemods.zip files represented the
>ongoing lynx development, combining your updates and updates contributed by
>other people. The mention of distinct (and divergent) "devel" code leaves me
>wondering which (if either) is in some sense the definitive version, which
>will eventually become the next "official" release, subject to any changes
>in the meantime.
>
>This wouldn't normally matter (wait for the next release, and it contains
>whatever it contains...), but having been forced into picking up an 
>intermediate version in order to get the security fixes, it raises the 
>question of continuity. With a large user population, it would be awkward if
>we were to install a version which included various new features which would
>vanish or behave differently in version 2.7.2 or whatever it may be called.
>
>(Fair enough if they turn out to be a bad idea and have to be changed or
>dropped for that reason, but it would be unfortunate to install "variant A",
>only to discover that "variant B" was the one which became 2.7.2, with
>inherently different and incompatible features.)

        The "devel" code, available via:

        http://www.slcc.edu/lynx/current/

is the "official Lynx development code" and wherever it goes is where Lynx
will be in its next "release", whenever that occurs.

        Virtually everything I've done in the fotemods has been
incorporated into to the devel code, though not necessarily identically.
I've also incorporated stuff from the devel code (done by others) into
the fotemods, though not necessarily identically.  However, there is
a lot more new or improved stuff in the devel code than I've incorporated
into the fotemods, as yet, if ever.

        For the most part, the fotemods can be considered a subset
of the devel code, albeit not entirely.  Two noteworthy differences
are:

        1) The devel code has changes in the Lynx caching and resubmission
           logic (a.k.a., "the INTERNAL_LINKS stuff") which precludes my,
           personally, using the devel code seriously.  If you are not
           using Lynx in conjunction with SSL, that's not as important
           for your site as it is for me, personally.

        2) The devel code does not apply chartrans handling to form
           attribute values, which in my, personal, view, precludes
           installing it for "production" use.  The chartrans handling
           is impefect for utf8 charsets, but it works quite well for
           all the others (and for form attribute values as well in
           the fotemods).

                                Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 address@hidden         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================
;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;