On Thursday, April 1, 2021 at 9:56:25 PM UTC+1, Chris Newman wrote:

In article <59165610...@tiscali.co.uk>,
John Williams (News) <UCE...@tiscali.co.uk> wrote:

In article <59165400...@waitrose.com>,
Chris Newman <cvj...@waitrose.com> wrote:

Interesting. Tim Hill's mimemap has...

application/x-spark Archive ddc .spk .lha .arj .lzh .hqx .uu .zoo

ie no &

But even more interesting it has:

application/zip Zip a91 .zip

application/x-zip Zip a91

which is what David was highlighting.

The & is not needed in MimeMap files - it is already understood.

Ah! Thanks for the explanation.

--
Chris Newman

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <6c40c01559.harriet@bazleyfamily.co.uk>, Harriet Bazley <harriet@bazleyfamily.co.uk> wrote:

On 31 Mar 2021 as I do recall, svrsig wrote:

[snip]

Adding an entry: application/x-zip-compressed Zip a91 to the MimeMap
file on my Titanium means that zip files from my web site are now downloaded with the the right file type on that computer. That is
therefore the solution - update your MimeMap file to include this
entry.

I already have application/zip application/x-compress application/x-zip application/compress

- is there not a consistent MIME type, or do all servers implement
their own?

It's probably a Linux/Windows/setting/Sysop thing. ;-)

--
from Tim Hill who welcomes incoming email to tim at timil dot com.
* Ethical? Energy: http://tjrh.eu/coopnrg Telecoms: http://tjrh.eu/phone
* Have a genuine & spam-proof address for Usenet http://www.invalid.org.uk/
* RISC OS downloads http://timil.com/riscos

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <7a1bcd3c-3b7f-481f-a1a2-d9cb5bec8387n@googlegroups.com>,
svrsig <chris@svrsig.org> wrote:

this will correct the user's MimeMap file.

Using a program to add an entry to the end of the file, after the
catch-all */* entry is probably not wise.

--

Tim Hill
Webmaster, https://timil.com

websites : php : RISC OS

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <59165610b9UCEbin@tiscali.co.uk>, John Williams (News) <UCEbin@tiscali.co.uk> wrote:

In article <591654001fcvjazz@waitrose.com>, Chris Newman
<cvjazz@waitrose.com> wrote:

Interesting. Tim Hill's mimemap has...

application/x-spark Archive ddc .spk .lha .arj .lzh .hqx .uu .zoo

ie no &

Any number is assumed to be hexadecimal in a mimemap file. This is not a
BBC Basic file. ;-)

But even more interesting it has:

application/zip Zip a91 .zip

It does! There's mention of this being added in the notes.

application/x-zip Zip a91

This is not in my mimemap file. Any idea how it came to be added to yours?

[Snip]

T

--

Tim Hill
Webmaster, https://timil.com

websites : php : RISC OS

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, April 22, 2021 at 6:04:21 PM UTC+1, Tim Hill wrote:

In article <7a1bcd3c-3b7f-481f...@googlegroups.com>,
svrsig <ch...@svrsig.org> wrote:

this will correct the user's MimeMap file.

Using a program to add an entry to the end of the file, after the
catch-all */* entry is probably not wise.

--

Tim Hill
Webmaster, https://timil.com

websites : php : RISC OS

The advice from ROOL (given on Sat, 15 Oct 2016 00:54:45 +0100)
to the question

Is there a recommended way to 'merge' a new definition into a user's
MimeMap file (like Boot Merge or System update)? I feel reluctant to
do it without user consent.

was

Well, the comments in the MimeMap file suggest that the first non
wildcarded line is given preference, so I suspect it's simply a matter of scanning the file for your MIME type, and if not found then appending your definition to the end of the file. Should be achievable in a few lines of single-tasking BASIC. A simple utility that did that and nothing else could
be made reusable by taking the MIME type, filetype and extensions from its arguments, then we could consider bunging that somewhere in !Boot for
others to use.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)