[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Correct one-line-description of cookie setting in textbrowser w3m needed



Hello Justin,

thank You for Your mail. One additional information on the background:
w3m is a textbrowser of age. Regrettably, the development team
vanished and documentation is scarce or difficult to understand. So I
hoped from help from other sides. A couple of problems with strings in
the configuration panel of w3m were already solved by reflecting the
context; it is the field of http and html.


Justin B Rye schrieb am 17. Oct 2014 um 00:53

> > I work on the german translation for the text-browser w3m. Within the
> > cookie settings, I doubt whether the short description of last of the
> > seven options on the option panel really fits to what is meant.
> >
> > section[8]: Cookie Settings
 
> It took me a while to work out that I wasn't meant to be finding this
> in the docs - it's a dialogue constructed out of strings in the source
> file "rc.c".
 
> > 1 use_cookie=<bool>                Enable cookie processing
> 
> (That really ought to be "use_cookieS", and likewise for most of the
> other variable names below.)

Indeed. But only the compiler needs to digest such variable names :-)


> > 2 show_cookie=<bool>               Print a message when receiving a cookie
> > 3 accept_cookie=<bool>             Accept cookies
> > 4 accept_bad_cookie=<number>       Action to be taken on invalid cookie
> 
> <number>?

<number> due to a set of values to be chosen from a pull-down menu.


> > 5 cookie_reject_domains=<string>   Domains to reject cookies from
> > 6 cookie_accept_domains=<string>   Domains to accept cookies from
> > 7 cookie_avoid_wrong_number_of_dots=<string> Domains to avoid [wrong number of dots]
> > 
> > My doubts began with the question what was the difference between
> > option 5 and 7, i.e. domains to reject and domains to
> > avoid. Meanwhile, I recieved hints to general information on cookie
> > processing and documention on w3m:
> > 
> > In file:///usr/share/doc/w3m/README.cookie it is explained
> > 
> >     If the number of "." in domain name is lesser than 2, it is
> >     assumed as invalid cookie (cf. RFC 2109 4.3.2), however, you can
> 
>       If the number of dots in the domain name is less than two, it is
>       treated as an invalid cookie (cf. RFC 2109 4.3.2). However, you can
> 
> >     use cookie_avoid_wrong_number_of_dots to avoid this
> >     restriction. You can set this in "Domains to avoid [wrong number
> >     of dots]" on the Option Setting Panel.
> 

> It's not a great variable name, either, because the user isn't being
> asked to specify one "wrong" number N which will configure w3m to
> reject cookies for domains with N dots - if I understand correctly,
> setting N=1 will cause w3m to reject as invalid all cookies for
> single-dotted *or* dotless domains (that is, it sets the minimum
> valid number of dots to two, which is just begging for off-by-one
> errors).  It's not quite clear if you can meaningfully set N=255.
> And... wait, why on earth is it a <string>?  What would it mean if I
> set N=fish?

The variable really gets a string. The RFC
(https://www.ietf.org/rfc/rfc2109.txt) establishes a general rule on
the position and the number of dots in the domain attribute of cookies
and the item of w3m's configuration we are talking about allows to
define exceptions.

Maybe the string fish as value for cookie_avoid_wrong_number_of_dots
is not as absurd as it seems. It fits to one case of the scheme of a
domain-lists given of w3m's README.cookie.


   domain-list = domains
               | ""
   domains     = domain
               | domain + "," + domains
   domain      = "." + domain-name      ; match with domain name
               | host-domain-name       ; match with HDN
               | ".local"               ; match with all HDN except which include  "."
               | "."                    ; match with all

                           (HDN: host domain name)

"fish" is no Fully qualified Domain Name FQDN but a host domain
name. For tests purposes, a local webserver installation could send
cookies with fish.local or .fish as value of the domain
attribute. According to 4.3.2 of the RFC mentioned above, such a
cookie is not acceptable.

I assume that the two configuration items cookie_accept_domains and
cookie_avoid_wrong_number_of_dots reflect to subsequent steps of
setting a cookie on the client side, i.e. computer running the
browser: 1. Is the sender of the cookie listed in domains to reject
cookies from?  2. Is the domain attribute of the cookie in accordance
with RFC 2109?  3. In case it is not: Does the domain attribute of the
cookie appear in the string value of cookie_avoid_wrong_number_of_dots?


> Tatsuya Kinoshita says
> # I'd like to use the "Domains to ..." style like other options.
> 
> That would be a good idea if this option was asking for a domain name
> string like the preceding options, but if it's really asking for an
> integer then it is a different kind of question and there's no point
> trying to contort it into the same style.

In fact the option asks for domain names.


> If we only get to fix the comment string and not the logic, I don't
> see any way of saying it that will fit - it would have to be
> something like:
> 
>   cookie_avoid_wrong_number_of_dots=<string> Reject cookies with this many dots or fewer in their domain
> or
>   cookie_avoid_wrong_number_of_dots=<string> Number of dots to treat as too few in domains

I did not want to reveal the suggestion I made in my bug report within
the first mail towards Your list. But my one line explanation for the
configuration item would be:

  cookie_avoid_wrong_number_of_dots=<string> "Do not reject cookies having one of the domain attributes"


> > The RFC (https://www.ietf.org/rfc/rfc2109.txt) explains
> [...]
> > I assume that the option in question refers to differences between the
> > domain of the server which is about to set a cookie on the computer of
> > the internet user and the domain attribute inside the cookie.
 
> I don't see any reason to assume that.

But the background of the RFC rules is security! A cookie shall only
interfere in communications between a specified webserver. A cookie
with a domain attribute "com.uk" would request for activation in any
communication with UK commercial sites.


> > Has anyone in Your team a suggestion for a-one-line description of
> > this option? I delivered one in my bug report [1]. Tatsuya as the
> > maintainer of the package w3m would as well appreciate Your help.
> > 
> > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765068
> 
> Meanwhile in ja.po it's:
> 
> 	"[wrong number of dots] ???????????????????????????"
> 
> (where the part in Japanese means something like "domains to ignore").
> This doesn't seem helpful at all.

If You know Japanese, give it a second thought! Think of a domain
attribute inside the cookie that shall not be checked for accordance
with the RFC. This is would be a request to ignore something.

Finally, a charming statement, found in a README file of the w3m
development team:

  If you can read English, see doc/*.
  If you can read Japanese, see doc-jp/*.
  If you can read both, read both and correct English. :-)


Sincerely
Markus


Reply to: