In message <7a1bcd3c-3b7f-481f-a1a2-d9cb5bec8387n@googlegroups.com>
on 22 Apr 2021 svrsig wrote:

> So if I add a short BASIC Programme to the !run files in my applications:
> 10 : P=OPENUP("Boot:Choices.Default.Internet.Files.MimeMap")
> 20 : IF P=0 THEN P=OPENUP("Boot:Resources.!Internet.Files.MimeMap")
> 30 : SYS "MimeMap_Translate","application/x-zip-compressed" TO roft%
> 40 : IF P<>0 THEN
> 50 : IF roft%=&FFD THEN
> 60 : PTR#P=EXT#P
> 70 : BPUT#P,"application/x-zip-compressed Zip A91"+CHR$13
> 80 : ENDIF
> 81 : CLOSE#P
> 82 : ENDIF
> 83 : OSCLI("ReadMimeMap")
> 84 : END
>
> this will correct the user's MimeMap file. Not quite sure about the syntax
> of MimeMap_Translate as it is not in the PRM nor on the ROOL web site.

I think there are various things wrong with that approach. I suspect the
user's choices and internet files settings should not be accessed just using
"Boot:" as there are system variables specifically designed to point to those
areas.

The MimeMap_Translate call needs correcting to:

SYS"MimeMap_Translate",2,"application/x-zip-compressed",0 TO ,,,roft%

I'm also not sure if it's appropriate to determine whether to add another
line like this. Your code does not distinguish between the MIME type being
mapped to FFD as a result of the */* catch-all line, and being explicitly
mapped by the user to FFD. What if the user wants to map this type to FFD?

The advice from ROOL talked about scanning the file, not using
MimeMap_Translate to determine whether to add the entry.

I think there are a few pitfalls here that need further consideration.

Going back upthread to your original problem, in investigating why the file
downloads as different filetypes on different computers, the missing piece of
the puzzle is what the web server is declaring the file to be in the HTTP
header. That should determine which file type is mapped to in NetSurf, not
the extension of the filename.

You need to examine the headers that the server is giving to the browser (the
developer tools in most modern browsers will help with this). It could be
that your web server needs reconfiguring as well.

--
Matthew Phillips
Durham

On 14 May 2021 as I do recall,
Matthew Phillips wrote:

[snip]

> Going back upthread to your original problem, in investigating why the file
> downloads as different filetypes on different computers, the missing piece of
> the puzzle is what the web server is declaring the file to be in the HTTP
> header. That should determine which file type is mapped to in NetSurf, not
> the extension of the filename.
>
> You need to examine the headers that the server is giving to the browser (the
> developer tools in most modern browsers will help with this). It could be
> that your web server needs reconfiguring as well.
>
HTTP/1.1 200 OK
Content-Type: application/x-zip-compressed
Last-Modified: Wed, 31 Mar 2021 07:19:43 GMT
Accept-Ranges: bytes
ETag: "f994ed38fe25d71:0"
Server: Microsoft-IIS/10.0
X-Powered-By: ASP.NET
Date: Fri, 14 May 2021 08:25:33 GMT
Content-Length: 1166853

Which, as said above in the thread, is causing problems in that
"application/x-zip-compressed" is not present in the MimeMap of those
downloading it (unless they edit their MimeMap files).

--
Harriet Bazley == Loyaulte me lie ==

Cleanliness is next to impossible.

In message <1003662c59.harriet@bazleyfamily.co.uk>
on 14 May 2021 Harriet Bazley wrote:

> On 14 May 2021 as I do recall,
> Matthew Phillips wrote:
>
>
> [snip]
>
>
> > Going back upthread to your original problem, in investigating why the file
> > downloads as different filetypes on different computers, the missing piece of
> > the puzzle is what the web server is declaring the file to be in the HTTP
> > header. That should determine which file type is mapped to in NetSurf, not
> > the extension of the filename.
> >
> > You need to examine the headers that the server is giving to the browser (the
> > developer tools in most modern browsers will help with this). It could be
> > that your web server needs reconfiguring as well.
> >
> HTTP/1.1 200 OK
> Content-Type: application/x-zip-compressed
> Last-Modified: Wed, 31 Mar 2021 07:19:43 GMT
> Accept-Ranges: bytes
> ETag: "f994ed38fe25d71:0"
> Server: Microsoft-IIS/10.0
> X-Powered-By: ASP.NET
> Date: Fri, 14 May 2021 08:25:33 GMT
> Content-Length: 1166853
>
> Which, as said above in the thread, is causing problems in that
> "application/x-zip-compressed" is not present in the MimeMap of those
> downloading it (unless they edit their MimeMap files).

Sorry - I missed that. I realise now that I had read all the parent messages
but not some of the other branches.

There can be a lot of variation in MIME types. Those with an "x-" in are
unregistered, and so will usually be replaced with a more appropriate
registered type at some stage. It is disappointing that Microsoft's IIS web
server is using such an outdated MIME type.

--
Matthew Phillips
Durham