Re: svn commit: r1791807 - /httpd/httpd/trunk/docs/conf/extra/httpd-manual.conf.in

[William A Rowe Jr]

On Apr 20, 2017 15:06, "André Malo"  wrote:

* William A Rowe Jr wrote:

> Please re-validate your assumptions before we proceed with this
> discussion. I'll be interested in your findings.

I did. I've decided to drop out of that "discussion".


I'm sorry if I offended you, or was too assertive in my tone. I did discover
one edge case as mentioned before where a missing language (or two) even
for nearly irrelevant content would introduce an unexpected result. That is
now fixed.

I hope this resolves the veto you raised...

I don't see what problem that's supposed to solve. On the contrary, since
the configured negotiation happens per file [1], removing languages, we do
provide somewhere does not make sense at all.

Please revert.


I hope at this point all of your concerns are addressed? If not I'll
entirely
revert 2.4.x in anticipation of a 2.4.26 tag soon-ish.

Re: svn commit: r1791807 - /httpd/httpd/trunk/docs/conf/extra/httpd-manual.conf.in

[André Malo]

* William A Rowe Jr wrote:

> Please re-validate your assumptions before we proceed with this
> discussion. I'll be interested in your findings.

I did. I've decided to drop out of that "discussion".

Cheers,

Re: svn commit: r1791807 - /httpd/httpd/trunk/docs/conf/extra/httpd-manual.conf.in

[André Malo]

* William A Rowe Jr wrote:

> On Tue, Apr 18, 2017 at 3:56 PM, André Malo  wrote:
> > * wr...@apache.org wrote:
> >> Author: wrowe
> >> Date: Tue Apr 18 16:25:03 2017
> >> New Revision: 1791807
> >>
> >> URL: http://svn.apache.org/viewvc?rev=1791807=rev
> >> Log:
> >> KISS: RemoveType is a simpler fix for .tr
> >
> > I seem to remember, that removetype does not override mime.types (only
> > addtype entries). But I might be wrong (and did not check now).
>
> I checked this in 2.4.x-dev branch, chrome could have lied, of course.

Hmm.
Ok, I looked it up. It was changed in 2.3.3. :-)

>
> >> explain .da files; order our
> >> LanguagePriority by a first-order comparison and drop negligable
> >> translations from our ordered priority preference list entirely.
> >
> > I don't see what problem that's supposed to solve. On the contrary,
> > since the configured negotiation happens per file [1], removing
> > languages, we do provide somewhere does not make sense at all.
>
> I'm not able to parse your thought here... let me clarify, and then
> please clarify your objection.
>
> The question of language priority is strictly one of the accuracy of one
> language variant over another.
>
> That question is largely answered by the browser, given three languages;
> fr q=1 en q=.8 ru q=.2 it says that this guest of your website is fluent
> in French, will comprehend English reasonably well, and can stumble
> through some Russian. So if the French can be served, we will serve it,
> and as all documents exist in English, we will fall back on that.
>
> The question isn't answered if this is a client with no matching
> languages, if only Estonian is given as a preferred language, we would
> normally serve a list of possible documents. That's foolish so we
> force-override with some sensible choice and an option to toggle between
> languages on every page.
>
> Where we find et q=1 fr q=.5 es q=.5 ... they will be equally comfortable
> with either French, or Spanish, since Estonian isn't available. Now which
> do we serve? That is where my edit comes in.
>
> The answer is invariably English because that is the source language.

Ehm? How is the whole negotation mechanism about the source language? Why 
would it care?

> Where equal-weight is given and we have two translations other than
> English to automatically fulfill, it must be the more relevant one.

Why? if it would matter, it would be given differently by the browser. Who 
are we to decide anyway? I would probably pick the first one and it might 
even be in accordance to the RFC (would need to check).

> We can't practically do this on a document-by-document basis

See above. Luckily there's no need to.

> so what is 
> your suggestion for prioritizing the most trustworthy (on our terms)
> translation where the user-agent refuses to give one or the other a
> higher priority?

My argument is about something completely different. It's not about the 
collection of documents, it about you come to the start page, could 
theoretically automatically see the danish variant but don't because it's 
not listed at all.

That's what you just killed, I think.

For the collection as a whole we added the prefer-language variable, which 
we use to give the user a simple choice between her preferred language and 
the source language (fallback).

Cheers,
-- 
sub the($){+shift} sub answer (){ord q
[* It is always 42! *]   }
   print the answer
# André Malo # http://pub.perlig.de/ #

Re: svn commit: r1791807 - /httpd/httpd/trunk/docs/conf/extra/httpd-manual.conf.in

[William A Rowe Jr]

On Tue, Apr 18, 2017 at 3:56 PM, André Malo  wrote:
> * wr...@apache.org wrote:
>
>> Author: wrowe
>> Date: Tue Apr 18 16:25:03 2017
>> New Revision: 1791807
>>
>> URL: http://svn.apache.org/viewvc?rev=1791807=rev
>> Log:
>> KISS: RemoveType is a simpler fix for .tr
>
> I seem to remember, that removetype does not override mime.types (only
> addtype entries). But I might be wrong (and did not check now).

Refusing to trust chrome, with the most recent conf change, from netcat I see...

HEAD /manual/tr/index.html.tr.utf8 HTTP/1.1
Host:localhost

HTTP/1.1 200 OK
Date: Tue, 18 Apr 2017 22:37:19 GMT
Server: Apache/2.4.25 (Unix) PivotalWebServer/6.2.3
OpenSSL/1.0.2j-fips mod_bmx/0.9.6
Last-Modified: Wed, 06 Apr 2016 11:34:46 GMT
ETag: "2423-52fcf59454180"
Accept-Ranges: bytes
Content-Length: 9251
Content-Type: text/html; charset=utf-8
Content-Language: tr

Re: svn commit: r1791807 - /httpd/httpd/trunk/docs/conf/extra/httpd-manual.conf.in

[William A Rowe Jr]

On Tue, Apr 18, 2017 at 3:56 PM, André Malo  wrote:
> * wr...@apache.org wrote:
>
>> Author: wrowe
>> Date: Tue Apr 18 16:25:03 2017
>> New Revision: 1791807
>>
>> URL: http://svn.apache.org/viewvc?rev=1791807=rev
>> Log:
>> KISS: RemoveType is a simpler fix for .tr
>
> I seem to remember, that removetype does not override mime.types (only
> addtype entries). But I might be wrong (and did not check now).

I checked this in 2.4.x-dev branch, chrome could have lied, of course.


>> explain .da files; order our
>> LanguagePriority by a first-order comparison and drop negligable
>> translations from our ordered priority preference list entirely.
>
> I don't see what problem that's supposed to solve. On the contrary, since
> the configured negotiation happens per file [1], removing languages, we do
> provide somewhere does not make sense at all.

I'm not able to parse your thought here... let me clarify, and then please
clarify your objection.

The question of language priority is strictly one of the accuracy of one
language variant over another.

That question is largely answered by the browser, given three languages;
fr q=1 en q=.8 ru q=.2 it says that this guest of your website is fluent in
French, will comprehend English reasonably well, and can stumble through
some Russian. So if the French can be served, we will serve it, and as all
documents exist in English, we will fall back on that.

The question isn't answered if this is a client with no matching languages,
if only Estonian is given as a preferred language, we would normally serve
a list of possible documents. That's foolish so we force-override with some
sensible choice and an option to toggle between languages on every page.

Where we find et q=1 fr q=.5 es q=.5 ... they will be equally comfortable
with either French, or Spanish, since Estonian isn't available. Now which
do we serve? That is where my edit comes in.

The answer is invariably English because that is the source language.
Where equal-weight is given and we have two translations other than
English to automatically fulfill, it must be the more relevant one. We
can't practically do this on a document-by-document basis, so what is
your suggestion for prioritizing the most trustworthy (on our terms)
translation where the user-agent refuses to give one or the other a
higher priority?

Re: svn commit: r1791807 - /httpd/httpd/trunk/docs/conf/extra/httpd-manual.conf.in

[André Malo]

* wr...@apache.org wrote:

> Author: wrowe
> Date: Tue Apr 18 16:25:03 2017
> New Revision: 1791807
>
> URL: http://svn.apache.org/viewvc?rev=1791807=rev
> Log:
> KISS: RemoveType is a simpler fix for .tr

I seem to remember, that removetype does not override mime.types (only 
addtype entries). But I might be wrong (and did not check now).

> explain .da files; order our 
> LanguagePriority by a first-order comparison and drop negligable
> translations from our ordered priority preference list entirely.

I don't see what problem that's supposed to solve. On the contrary, since 
the configured negotiation happens per file [1], removing languages, we do 
provide somewhere does not make sense at all.

Please revert.

[1] if you do not specifically select a preferred language via the path 
magic

Cheers,
-- 
Treat your password like your toothbrush. Don't let anybody else
use it, and get a new one every six months.  -- Clifford Stoll

(found in ssl_engine_pphrase.c)