David Philip wrote:
> [EMAIL PROTECTED] wrote:
>
>
> Makes sense. Then it's easy to see what version of mozilla is being
> used for purposes of HTTP logging. As long as the bit after the
> decimal point has an obvious connection to the current mozilla
> version (e.g. 1.2 = Mozilla/5.12 3.4 = Mozilla/5.34)
I know a lot of log analysis software reports all versions of Mozilla
and Netscape 6 as Netscape Navigator 5.0 because it sees the Mozilla/5.0
and there's no mention of Opera or MSIE so it assumes it's a Netscape
release and Netscape traditionally has the version after Mozilla/
Although implementing my proposed solution wouldn't correct the log
reporting. It would make Mozilla 1.0 and derivative browsers report
themselves as Netscape 5.1 then it helps distinguish the various
releases in the logs.
Also remember in the user agent spec the contents of the brackets are
meant to be comments, the version should be represented in a meaningful
manner in the main ID string.
>>
>> Mozilla/6.0 could come at a later date if there's a big enough
>> change to warrant moving up a major version number.
>
>
> What sort of 'big change' do you mean? Support for a new protocol,
support
> for new markup/scripting languages (WML, SVG, MathML, etc)
No idea, when the move to Mozilla/6.x is deemed necessary would be the
basis of discussion on here but it's not the time for that yet.
>>
>
> You mean here:
>
> http://www.mozilla.org/build/revised-user-agent-strings.html ?
That's the one!
>
> Content negotiation is not a valid reason for designing user-agent
strings,
> although that doesn't stop anyone :)
>
Well basically the idea is to encourage anyone who does decide to base
content on the useragent to use the version represented by
Mozilla/version rather than rely on a vendor supplied version number
which will only be present in the vendor branded releases.
>> Remember Mozilla and Netscape 6 have a translate function in the
>> view menu. This serves some remote XUL to Mozilla. This sends to
>> old mime type and XUL syntax so that it works in Netscape 6. I'm
>> sure the vendors want to ensure Netscape 6 still works while
>> supporting Mozilla 1.0 and NS 6.5, therefore searching for
>> Mozilla/5.1 user agent will indicate that the new mime type and
>> syntax should be sent.
>
>
> I don't know about XUL in Mozilla, but if changes in the latest
> version mean the translate function won't work properly in the new
> releases then something needs to be done to enable it to work
> while retaining compatibility with Netscape 6.0. Where is XUL used
> in the translate function all I get is a web page?
The XUL is in a bar at the top of the translated page.
> If possible we should not use User agent sniffing for this though.
I think user agent sniffing would be the only option for the translate
page as it'd need to return a different mime type based on the browser
version. The user agent is sent by the browser when the request for the
page is made so the server can work out the correct mime type to send.
>
> Anyway, I've added .netlib to this post as other people have posted user
> agent comments there but kept followups to .seamonkey
I should have posted to netlib in the firstplace, but here's hoping that
people on the netlib list have seen your post and will follow it on
n.p.m.seamonkey I'll keep the followups just going into .seamonkey, if
people consider it more suited to netlib you can switch the followups
accordingly.
