From: Gabriele B. <bar...@in...> - 2003-10-24 03:47:31
|
Guys, can you please revise the defaults.cc documentation for the 'head_before_get' attribute. I wrote something but it needs some revision by english mother-tongue developers. Also, I didn't generate the documentation by purpose. Please let's remember to do it before we go in release. Ciao, -Gabriele -- Gabriele Bartolini: Web Programmer, ht://Dig & IWA/HWG Member, ht://Check maintainer Current Location: Melbourne, Victoria, Australia bar...@in... | http://www.prato.linux.it/~gbartolini | ICQ#129221447 > "Leave every hope, ye who enter!", Dante Alighieri, Divine Comedy, The Inferno |
From: Lachlan A. <lh...@us...> - 2003-10-24 16:21:16
|
On Thu, 23 Oct 2003 21:51, Gabriele Bartolini wrote: > can you please revise the defaults.cc documentation for the > 'head_before_get' attribute. I wrote something but it needs some > revision by english mother-tongue developers. Your English is fine. I've made a few changes below, if you're=20 interested (but it was OK as it was). Cheers, Lachlan If set to true, an HTTP/1.1 <em>HEAD</em> call is made in order to retrieve header information about a document. If the status code and the content-type returned show that the=20 document is parsable, then a subsequent 'GET' call is made. In=20 general, it is recommended that this attribute be set to 'true', as it can really improve performance (especially when used with=20 persistent connections). This is particularly so during an=20 incremental dig, since in this case 'htdig' can ask the server if the=20 document has been modified since last dig. However there are a few=20 cases when it is better to switch it off: <ul> <li>the majority of documents are parsable (HTML or a type for which=20 an external parser has been provided) and must be retrieved anyway=20 (initial dig);</li>=20 <li>the server does not support the HEAD method or it is=20 disabled;</li>=20 <li>in some cases persistent connections (<a href=3D\"#persistent_connections\">persistent_connections</a>) may=20 not work properly and either the 'head_before_get' attribute or the=20 'persistent_connections' attribute must be turned off. </li> </ul> --=20 lh...@us... ht://Dig developer DownUnder (http://www.htdig.org) |
From: Gabriele B. <bar...@in...> - 2003-10-25 09:54:26
|
At 23.01 24/10/2003 +1000, Lachlan Andrew wrote: >On Thu, 23 Oct 2003 21:51, Gabriele Bartolini wrote: > > > can you please revise the defaults.cc documentation for the > > 'head_before_get' attribute. I wrote something but it needs some > > revision by english mother-tongue developers. > >Your English is fine. I've made a few changes below, if you're >interested (but it was OK as it was). Thanks Lachlan. :-) I will change the defaults.cc file asap. I am not on Linux now, I will do it when I come back or tomorrow morning. -Gabriele -- Gabriele Bartolini: Web Programmer, ht://Dig & IWA/HWG Member, ht://Check maintainer Current Location: Melbourne, Victoria, Australia bar...@in... | http://www.prato.linux.it/~gbartolini | ICQ#129221447 > "Leave every hope, ye who enter!", Dante Alighieri, Divine Comedy, The Inferno |
From: Lachlan A. <lh...@us...> - 2003-10-25 16:20:12
|
Greetings all, I've found the problem: In setVariables(), the command=20 vars.Add("PAGEHEADER", new String(config->Find("page_list_header"))); is executed before the command vars.Add("PAGELIST", str); That means that ${PAGELIST} is expanded as empty when the string is=20 created. Swapping the order of these solves the particular problem, but the=20 more fundamental problem is that any variable can (or should be able=20 to be) defined in terms of any other, and there is no ordering which=20 can allow that. One possibility would be to go through and set each=20 variable *twice*, so that second time around, most variables should=20 have their right values. Of course, chains of variables defined in=20 terms of each other would need more than two iterations... Another option would be to merge vars with config so that the=20 literal string ${PAGELIST} would be added, and only evaluated when=20 the variable is finally expanded during output. Cheers, Lachlan On Fri, 24 Oct 2003 22:49, Lachlan Andrew wrote: > Are variables in (no_)page_list_header supposed to be expanded? > > If page_list_header =3D ${PAGELIST} then PAGEHEADER is empty when > there is more than one page, even though PAGELIST isn't. --=20 lh...@us... ht://Dig developer DownUnder (http://www.htdig.org) |
From: Gilles D. <gr...@sc...> - 2003-10-27 21:51:18
|
According to Lachlan Andrew: > Swapping the order of these solves the particular problem, but the > more fundamental problem is that any variable can (or should be able > to be) defined in terms of any other, and there is no ordering which > can allow that. One possibility would be to go through and set each > variable *twice*, so that second time around, most variables should > have their right values. Of course, chains of variables defined in > terms of each other would need more than two iterations... > > Another option would be to merge vars with config so that the > literal string ${PAGELIST} would be added, and only evaluated when > the variable is finally expanded during output. I think it's very important to keep a distinction between configuration attributes and template variables. They're two distinct things, and for good reason. I had thought a while ago, when adding to htsearch the ability to reference any environment variable from a template, that it might be a good idea also to be able to do so for any config attribute as well. Then it occurred to me that this could be a security risk, as it would be too easy to reveal sensitive config information in a result template, if you're not careful. Right now, you can put an attribute name in allow_in_form to turn it into a CGI parameter and related template variable. It might make sense to also add an allow_in_template attribute, to do just the config to template relationship, without also the CGI parameter to config relationship, so that you can securely expose some config attributes to the templates without allowing a web user to override them. However, I'd advise against a wholesale merging of config attributes and template variables. -- Gilles R. Detillieux E-mail: <gr...@sc...> Spinal Cord Research Centre WWW: http://www.scrc.umanitoba.ca/ Dept. Physiology, U. of Manitoba Winnipeg, MB R3E 3J7 (Canada) |