docs@httpd.apache.org Archives

Re: DBDParams argument format

2009-12-03T23:53:41Z


If supplying multiple servers to an AuthLdapUrl then it needs to be quoted as well.
(As denoted in trunk: http://httpd.apache.org/docs/trunk/mod/mod_authnz_ldap.html#authldapurl
but not in 2.2, where it is valid as well.)

----- "Rich Bowen"  wrote:

> On Nov 28, 2009, at 18:02 , Vincent Bray wrote:
> 
> 
> 2009/11/28 Rich Bowen < rbowen@rcbowen.com >:
> 
> 
> If both work, then the canonical format should be spaces, not commas.
> Making
> 
> 
> it commas would make it the odd duck among all of our directives, and
> I'd
> 
> 
> prefer to avoid that.
> 
> To be clear, the spaced format argument must be quoted to be a single
> argument. Is there a precedent for such a
> multi-valued-single-parameter? I can't recall one.
> 
> Nothing comes to mind. Except something like piped log handlers, where
> the entire pipe command needs to be quoted, but that's not really the
> same thing.
> 
> 
> 
> --
> Rich Bowen
> rbowen@rcbowen.com

-- 
Igor Galić

Tel: +43 (0) 699 122 96 338
Fax: +43 (0) 1 90 89 226
Mail: i.galic@brainsware.org
URL: http://brainsware.org/

---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org

Re: document translation infrastructure?

2009-12-02T12:25:55Z

* Miles Libbey wrote: 


> Hi folks-
> I work in the Traffic Server incubator project, and have had our first
> request to translate documentation from English into Korean.
>
> I think I missing something in the process that Paul describes.  Sounds
> like:
> 1. Someone makes a change to the English docbook/xml file, and submits a
> patch.
> 2. The patch gets reviewed, and assuming high quality changes, gets
> committed

usually the people directly commit it. The English documentation has CTR 
policy (commit then review).

> 3. something happens in which all the xml.{language_code} files get a
> new "English Revision" comment [what's the something and it's
> surrounding process?], and I'm guessing all reviewed by/{language}
> translation comments get removed.

The English documents (xml) are authoritative. They have the 
LastChangedRevision property set which is filled inside a comment by every 
subversion checkout.

The translator of a document adds a comment to the translation, which 
contains the svn revision number the translation is based on (also within a 
comment, with a specified format).

The build system does the following on every run:

- check which translations exist
- check the LastChangedRevision of the english documents against each 
  translation and if it is different from the translator's comment, the 
  comment is changed to contain the original translator's base revision and 
  the new one of the english document. These generated comments are further
  modified if the English document changes again.
- generate "meta" files for each english document, which contain the 
  information collected above: which languages are available and whether 
  they are outdated or not.
- these meta files are included in the transformation process (xslt) to 
  generate the final html files and typemaps for mod_negotiation.
- Additionally for each language build a list of outdated files is emitted 
  on the console.

[...]


> 6. Something transforms the xml into html.  When transforming,
>   - if there is a (outdated) reference, the language site gets a "This
> translation may be out of date" message on the relevant pages (including
> the index).

Yes.

>   - the html files are copied to a language directory, removing the
> .{language_code} from the file name in the process
> [when does this happen? Is the priority to get a better English version
> out quickly or give other languages a chance to catch up before a push
> date?]

See the typemap story above. There's a corresponding httpd configuration 
working with the typemaps.

nd

---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org

Re: document translation infrastructure?

2009-12-01T22:33:02Z

Hi folks-
I work in the Traffic Server incubator project, and have had our first 
request to translate documentation from English into Korean.

I think I missing something in the process that Paul describes.  Sounds 
like:
1. Someone makes a change to the English docbook/xml file, and submits a 
patch.
2. The patch gets reviewed, and assuming high quality changes, gets 
committed
3. something happens in which all the xml.{language_code} files get a 
new "English Revision" comment [what's the something and it's 
surrounding process?], and I'm guessing all reviewed by/{language} 
translation comments get removed.
4. Translators run something like
  svn update
  grep "(outdated) -->" *.xml.fr
to get a list of files that are outdated.  [is there something that 
prompts translators to do this?]
5. Translators submit patches (including changing the "English Revision" 
comment to remove the outdated reference, and their name in a 
translation comment), a second person reviews.  Assuming high quality 
changes the second person adds their name to a reviewed by comment, and 
the change is checked in.
6. Something transforms the xml into html.  When transforming,
  - if there is a (outdated) reference, the language site gets a "This 
translation may be out of date" message on the relevant pages (including 
the index).
  - the html files are copied to a language directory, removing the 
.{language_code} from the file name in the process
[when does this happen? Is the priority to get a better English version 
out quickly or give other languages a chance to catch up before a push 
date?]

Roughly correct?

Our current documentation is HTML based -- is there anything about the 
httpd doc process that could not be done for html (vs xml)?

Thanks!
miles libbey

Paul Querna may have written the following on 11/25/09 11:41 AM:
> (adding docs@httpd cc)
>
> On Tue, Nov 24, 2009 at 10:20 AM, Miles Libbey  wrote:
>> Hi folks-
>> We have a volunteer to translate our documentation from English into Korean.
>>   Any recommendations for translation management/infrastructure? That is-- as
>> the english documentation changes, is there any software that can help to
>> find out of date or new strings/sections?
>
> I would recommend looking at or copying how the httpd project handles
> documentation translation.
>
>    Explains some
> of the basics.
>
> For translations, the build keeps track of what subversion revs
> changes a english version of the document, and then modifies the
> non-english translations with information about the missing revisions.
>   On the generated output, it also automatically adds a banner saying
> that the file is out of date compared to the english version.
>
> A concrete example:
> 
> is the current english version of the bind() docs.'
>
> the meta file keeps track of which translations are outdated:
> 
>
> If you look at the german translation:
> 
> You can see it keeps a comment at the top of the file, tracking the
> SVN revisions the english version has over the german version:
> 
>
> For the translater, they can then run svn log/diff over that rev range
> and update their translation.
>
> This system seems to work pretty well for docs@httpd, and I imagine it
> could be adopted to raw HTML.
>
> Someone from docs@httpd could likely explain it better....

---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org

Re: DBDParams argument format

2009-11-28T23:52:43Z


On Nov 28, 2009, at 18:02 , Vincent Bray wrote:

> 2009/11/28 Rich Bowen :
>> If both work, then the canonical format should be spaces, not  
>> commas. Making
>> it commas would make it the odd duck among all of our directives,  
>> and I'd
>> prefer to avoid that.
>
> To be clear, the spaced format argument must be quoted to be a single
> argument. Is there a precedent for such a
> multi-valued-single-parameter? I can't recall one.

Nothing comes to mind. Except something like piped log handlers, where  
the entire pipe command needs to be quoted, but that's not really the  
same thing.

--
Rich Bowen
rbowen@rcbowen.com

Re: DBDParams argument format

2009-11-28T23:02:04Z

2009/11/28 Rich Bowen :
> If both work, then the canonical format should be spaces, not commas. Making
> it commas would make it the odd duck among all of our directives, and I'd
> prefer to avoid that.

To be clear, the spaced format argument must be quoted to be a single
argument. Is there a precedent for such a
multi-valued-single-parameter? I can't recall one.

-- 
noodl

---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org

Re: DBDParams argument format

2009-11-28T22:29:13Z

If both work, then the canonical format should be spaces, not commas.  
Making it commas would make it the odd duck among all of our  
directives, and I'd prefer to avoid that.


On Nov 28, 2009, at 12:48 , Vincent Bray wrote:

> There is some confusion in the DBD docs about the format of the
> argument to the DBDParams directive.
>
> http://httpd.apache.org/docs/2.2/mod/mod_dbd.html#dbdparams
> This suggests that arguments should be comma separated.
>
> http://httpd.apache.org/docs/2.2/mod/mod_authn_dbd.html#example
> And this one uses spaces.
>
> I've tested both formats and they both appear to work. The code in
> apr-util/dbd for parsing the parameter is somewhat impenetrable to me
> so before fixing up the docs, it would help to know which format
> should be canonical.
>
> Plz help ktnx.
>
> -- 
> noodl
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
> For additional commands, e-mail: docs-help@httpd.apache.org
>

--
Rich Bowen
rbowen@rcbowen.com




---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org

DBDParams argument format

2009-11-28T17:48:10Z

There is some confusion in the DBD docs about the format of the
argument to the DBDParams directive.

http://httpd.apache.org/docs/2.2/mod/mod_dbd.html#dbdparams
This suggests that arguments should be comma separated.

http://httpd.apache.org/docs/2.2/mod/mod_authn_dbd.html#example
And this one uses spaces.

I've tested both formats and they both appear to work. The code in
apr-util/dbd for parsing the parameter is somewhat impenetrable to me
so before fixing up the docs, it would help to know which format
should be canonical.

Plz help ktnx.

-- 
noodl

---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org

Re: document translation infrastructure?

2009-11-25T19:41:22Z

(adding docs@httpd cc)

On Tue, Nov 24, 2009 at 10:20 AM, Miles Libbey  wrote:
> Hi folks-
> We have a volunteer to translate our documentation from English into Korean.
>  Any recommendations for translation management/infrastructure? That is-- as
> the english documentation changes, is there any software that can help to
> find out of date or new strings/sections?

I would recommend looking at or copying how the httpd project handles
documentation translation.

  Explains some
of the basics.

For translations, the build keeps track of what subversion revs
changes a english version of the document, and then modifies the
non-english translations with information about the missing revisions.
 On the generated output, it also automatically adds a banner saying
that the file is out of date compared to the english version.

A concrete example:

is the current english version of the bind() docs.'

the meta file keeps track of which translations are outdated:

If you look at the german translation:

You can see it keeps a comment at the top of the file, tracking the
SVN revisions the english version has over the german version:

For the translater, they can then run svn log/diff over that rev range
and update their translation.

This system seems to work pretty well for docs@httpd, and I imagine it
could be adopted to raw HTML.

Someone from docs@httpd could likely explain it better....

---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org

Re: svn commit: r832627 - in /httpd/httpd/trunk/docs/manual/mod: mod_rewrite.html.en mod_rewrite.xml

2009-11-21T21:13:04Z

* noirin@apache.org wrote:

> Author: noirin
> Date: Wed Nov  4 00:10:36 2009
> New Revision: 832627
>
> URL: http://svn.apache.org/viewvc?rev=832627&view=rev
> Log:
> Split RewriteCond into two sections, brought TestString section up to
> date.

s inside are  are not allowed (use build validate-xml to 
check against the DTD).
I suggest, to move stuff out of the  block completely instead and 
reference from there.

nd
-- 
"Solides und umfangreiches Buch"
                                          -- aus einer Rezension



---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org

Re: rewrite/access.xml

2009-11-21T17:33:48Z

Thanks. Applied in r882945


On Nov 21, 2009, at 11:31 , Lucien GENTIS wrote:

> Hello all,
>
> file rewrite/access.xml - line 249
>
> shouldn't it rather be
>
> "you should drop the second condition" instead of
> "you should drop the second rule" ?
>
> cheers
>
> Lucien
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
> For additional commands, e-mail: docs-help@httpd.apache.org
>

--
Rich Bowen
rbowen@rcbowen.com




---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org

rewrite/access.xml

2009-11-21T16:31:28Z

Hello all,

file rewrite/access.xml - line 249

shouldn't it rather be

"you should drop the second condition" instead of
"you should drop the second rule" ?

cheers

Lucien

---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org

Re: Rewrite Flags

2009-11-20T11:56:51Z

2009/11/20 Tero Lampiluoto :
> I think behaviour of R flag has changed at some point of 2.2.x,
> imho it earlier accepted only certain HTTP status codes.
>
> Does someone have more accurate information on this?

Here's the revision that introduced that change, from Jan '04

http://svn.apache.org/viewvc?view=revision&revision=102321

-- 
noodl

---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org

Re: Rewrite Flags

2009-11-20T10:56:19Z

I haven't tested it with 2.3, but will do.

In 2.2, I tested it with all valid HTTP status codes, and it accepted  
all of them.

On Nov 20, 2009, at 01:42 , Tero Lampiluoto wrote:

> Hello,
>
> I think behaviour of R flag has changed at some point of 2.2.x,
> imho it earlier accepted only certain HTTP status codes.
>
> Does someone have more accurate information on this?
> Obviously some testing would solve this out as well... Because
> the version information should be mentioned to avoid unnecessary
> confusion as number of users have older versions provided e.g. by
> their distro.
>
> -- 
> Tero Lampiluoto
> lampiluoto at gmail com
> lamp
>
> On Thu, Nov 19, 2009 at 5:12 PM, Rich Bowen   
> wrote:
>> Thanks. Applied r882171.
>>
>> On Nov 19, 2009, at 10:06 , Igor Galić wrote:
>>
>>>
>>> Hi folks,
>>>
>>> here's a small fix to the new rewrite guide's flags.xml:
>>> R= can be *any* (valid) HTTP response.
>>>
>>> Bye,
>>>
>>> --
>>> Igor Galić
>>>
>>> Tel: +43 (0) 699 122 96 338
>>> Fax: +43 (0) 1 90 89 226
>>> Mail: i.galic@brainsware.org
>>> URL: http://brainsware.org/
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
>>> For additional commands, e-mail: docs-help@httpd.apache.org
>>
>> --
>> Rich Bowen
>> rbowen@rcbowen.com
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
>> For additional commands, e-mail: docs-help@httpd.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
> For additional commands, e-mail: docs-help@httpd.apache.org
>

--
Rich Bowen
rbowen@rcbowen.com




---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org

Re: Rewrite Flags

2009-11-20T06:42:55Z

Hello,

I think behaviour of R flag has changed at some point of 2.2.x,
imho it earlier accepted only certain HTTP status codes.

Does someone have more accurate information on this?
Obviously some testing would solve this out as well... Because
the version information should be mentioned to avoid unnecessary
confusion as number of users have older versions provided e.g. by
their distro.

-- 
 Tero Lampiluoto
 lampiluoto at gmail com
 lamp

On Thu, Nov 19, 2009 at 5:12 PM, Rich Bowen  wrote:
> Thanks. Applied r882171.
>
> On Nov 19, 2009, at 10:06 , Igor Galić wrote:
>
>>
>> Hi folks,
>>
>> here's a small fix to the new rewrite guide's flags.xml:
>> R= can be *any* (valid) HTTP response.
>>
>> Bye,
>>
>> --
>> Igor Galić
>>
>> Tel: +43 (0) 699 122 96 338
>> Fax: +43 (0) 1 90 89 226
>> Mail: i.galic@brainsware.org
>> URL: http://brainsware.org/
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
>> For additional commands, e-mail: docs-help@httpd.apache.org
>
> --
> Rich Bowen
> rbowen@rcbowen.com
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
> For additional commands, e-mail: docs-help@httpd.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org

Re: Rewrite Flags

2009-11-19T15:12:01Z

Thanks. Applied r882171.

On Nov 19, 2009, at 10:06 , Igor Galić wrote:

>
> Hi folks,
>
> here's a small fix to the new rewrite guide's flags.xml:
> R= can be *any* (valid) HTTP response.
>
> Bye,
>
> -- 
> Igor Galić
>
> Tel: +43 (0) 699 122 96 338
> Fax: +43 (0) 1 90 89 226
> Mail: i.galic@brainsware.org
> URL: http://brainsware.org/
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
> For additional commands, e-mail: docs-help@httpd.apache.org

--
Rich Bowen
rbowen@rcbowen.com




---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org

Rewrite Flags

2009-11-19T15:06:58Z


Hi folks,

here's a small fix to the new rewrite guide's flags.xml:
R= can be *any* (valid) HTTP response.

Bye,

-- 
Igor Galić

Tel: +43 (0) 699 122 96 338
Fax: +43 (0) 1 90 89 226
Mail: i.galic@brainsware.org
URL: http://brainsware.org/

mod_rewrite

2009-11-17T16:14:54Z

The rewrite_guide.html file has been divvied up into topic-specific  
chunks. There are still some recipes in the 'advanced' doc that need  
to be fixed. And I'd like to do a [P] doc, and possibly a vhost doc.  
But I think it's a huge step forward, and almost all of the examples  
actually work now.

--
Rich Bowen
rbowen@rcbowen.com




---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org

Re: Performance tuning documentation

2009-11-13T11:39:13Z


----- "Graham Leggett"  wrote:

> Rich Bowen wrote:
> 
> > The performance tuning documentation that we currently include in
> the
> > docs is simply awful. What with the comments about Apache 1.2 and
> the
> > suggestions of how to deal with the new Linux 2.0 kernel, I think
> it's
> > beyond fixing. It needs to be tossed and rewritten - although
> perhaps
> > there are parts that are salvageable.
> > 
> > I was wondering if someone has a performance doc that they could
> > contribute as a starting place? Perhaps Sander's talk from AC? Or
> if
> > someone would be willing to give some attention to the docs list for
> a
> > while to assist in writing something that would be useful to actual
> > admins in the real world.
> 
> Something else related that I think we should address are our default
> config files and performance.
> 
> Up till now, the build has assumed that if a module was built, then a
> LoadModule line should appear in the default config file for that
> module. Because distros typically compile most (if not all) of the
> modules, most (if not all) of the modules end up being loaded into
> the
> server by default, in turn meaning lots of hook calling and
> per-request
> config parsing is being done for no reason.

It's been a long time now, but I still remember Rich asking for a
Apache httpd starting *without* a config.
I'm not sure this is easily doable, but I'm pretty confident that
we can slim down the basic config (httpd.conf) to a very minimalistic
level and put all the fluff in extra

Matthew's configs are pretty good example of how to do it right:

http://www.linux-corner.info/httpd/httpd.conf
http://www.linux-corner.info/httpd/httpd-simple.conf

They are short and quite clear on what they,

> [snip]

So long
-- 
Igor Galić

Tel: +43 (0) 699 122 96 338
Fax: +43 (0) 1 90 89 226
Mail: i.galic@brainsware.org
URL: http://brainsware.org/

---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org

Re: Performance tuning documentation

2009-11-13T10:52:26Z

Rich Bowen wrote:

> The performance tuning documentation that we currently include in the
> docs is simply awful. What with the comments about Apache 1.2 and the
> suggestions of how to deal with the new Linux 2.0 kernel, I think it's
> beyond fixing. It needs to be tossed and rewritten - although perhaps
> there are parts that are salvageable.
> 
> I was wondering if someone has a performance doc that they could
> contribute as a starting place? Perhaps Sander's talk from AC? Or if
> someone would be willing to give some attention to the docs list for a
> while to assist in writing something that would be useful to actual
> admins in the real world.

Something else related that I think we should address are our default
config files and performance.

Up till now, the build has assumed that if a module was built, then a
LoadModule line should appear in the default config file for that
module. Because distros typically compile most (if not all) of the
modules, most (if not all) of the modules end up being loaded into the
server by default, in turn meaning lots of hook calling and per-request
config parsing is being done for no reason.

A pattern I've adopted is to put the load module alongside the config
fragment that requires it, like this:

  LoadModule foo_module mod_foo.so

If the config fragment isn't used, the corresponding module isn't loaded.

Regards,
Graham
--

---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org

Performance tuning documentation

2009-11-12T16:30:22Z

The performance tuning documentation that we currently include in the  
docs is simply awful. What with the comments about Apache 1.2 and the  
suggestions of how to deal with the new Linux 2.0 kernel, I think it's  
beyond fixing. It needs to be tossed and rewritten - although perhaps  
there are parts that are salvageable.

I was wondering if someone has a performance doc that they could  
contribute as a starting place? Perhaps Sander's talk from AC? Or if  
someone would be willing to give some attention to the docs list for a  
while to assist in writing something that would be useful to actual  
admins in the real world.

--
Rich Bowen
rbowen@rcbowen.com




---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org

Re: seems stale

2009-11-12T07:22:47Z

On Wed, Nov 11, 2009 at 10:38:23PM -0600, William A. Rowe Jr. wrote:
> None of the first paragraph here seems relevant to 2.0 through trunk;
> 
>   http://httpd.apache.org/docs/2.2/ssl/ssl_compat.html
> 
> WDYT?  Mop-up time?
> 
I'm thinking it'd almost be better just to get rid of the whole page.
If not, most of it probably needs to be rewritten to compare to slightly
more recent things.
The only thing that seems useful to me is the Custom Log Functions section.

vh

Mads Toftum
-- 
http://soulfood.dk

---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org

seems stale

2009-11-12T04:38:23Z

None of the first paragraph here seems relevant to 2.0 through trunk;

  http://httpd.apache.org/docs/2.2/ssl/ssl_compat.html

WDYT?  Mop-up time?

---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org

Re: manual/rewrite/remapping.xml

2009-11-07T17:42:37Z

Thanks. Applied r833721.

It would be great if folks would pitch in and help with the reorg of  
the rewrite guide. Basically we're splitting it into sub-docs, and, in  
the process, correcting the numerous errors, and improving the  
phrasing to be less "gee, look what I can do" and more helpful and  
hand-holding.

--Rich

On Nov 7, 2009, at 08:40 , Lucien GENTIS wrote:

> Hi to all,
>
> Trunk branch - file manual/rewrite/remapping.xml - line194 :
>
> "Consequently, $1 is already defined by the time the RewriteRule
> directives are evaluated."
>
> Shouldn't it be instead
>
> "Consequently, $1 is already defined by the time the RewriteCond
> directives are evaluated." ?
>
> Lucien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
> For additional commands, e-mail: docs-help@httpd.apache.org
>

--
Rich Bowen
rbowen@rcbowen.com




---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org

manual/rewrite/remapping.xml

2009-11-07T16:40:25Z

Hi to all,

Trunk branch - file manual/rewrite/remapping.xml - line194 :

"Consequently, $1 is already defined by the time the RewriteRule
directives are evaluated."

Shouldn't it be instead

"Consequently, $1 is already defined by the time the RewriteCond
directives are evaluated." ?

Lucien


---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org

manual/rewrite/remapping.xml

2009-11-07T16:39:28Z

Hi to all,

Trunk branch - file manual/rewrite/remapping.xml - line194 :

"Consequently, $1 is already defined by the time the RewriteRule
directives are evaluated."

Shouldn't it be instead

"Consequently, $1 is already defined by the time the RewriteCond
directives are evaluated." ?

Lucien


---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org

Re: rewrite rule user dir as subdomain

2009-11-05T15:35:19Z

There is actually already that example in the rewrite guide. Like many  
of the other examples, it is well concealed, and doesn't work very  
well. Using mod_rewrite for this causes a number of things to break on  
an alarmingly regular basis - most significantly, dynamic thingies  
tend to get served as static files all too often.

One of the new main focuses of the rewrite guide is to nudge people  
towards solutions that don't use mod_rewrite, such as, in this case,  
mod_vhost_alias.

The sheer number of people who are doing virtualhosting at  
the .htaccess file level is pretty alarming.

On Nov 5, 2009, at 01:58 , Mario Brandt wrote:

> Hi!
> I've often been asked how to make userdir as a sudomain.
>
> Maybe that can be as well in the rewrite guide.
>
>
> cheers
> Mario
>
>
>
> DocumentRoot /webhosts/
>
> [...]
>
> 
> ServerAlias www.example.com
> ServerName www.example.com
> RewriteEngine  on
> RewriteCond    %{HTTP_HOST}  ^example.com
> RewriteRule    ^(.*)$        /www/$1 [L]
> RewriteCond    %{HTTP_HOST}  ^www.*
> RewriteRule    ^(.*)$        /www/$1 [L]
> RewriteCond    %{HTTP_HOST}  ^(.*)\.example\.com
> RewriteRule    ^(.*)$        /%1/$1 [L]
> 
>
> Will be translated to
>
> www.yourdomain.com => /webhosts/www/
> muon.yourdomain.com => /webhosts/muon/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
> For additional commands, e-mail: docs-help@httpd.apache.org
>

--
Rich Bowen
rbowen@rcbowen.com

---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org

Re: rewrite rule user dir as subdomain

2009-11-05T10:10:03Z

On Thu, Nov 05, 2009 at 10:58:17AM +0100, Mario Brandt wrote:
> Hi!
> I've often been asked how to make userdir as a sudomain.
> 
> Maybe that can be as well in the rewrite guide.
> 
Actually that's one of my common examples of where mod_rewrite is being
used excessively. For the general case, mod_vhost_alias is usually a
much better choice.

vh

Mads Toftum
-- 
http://soulfood.dk

---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org

rewrite rule user dir as subdomain

2009-11-05T09:58:17Z

Hi!
I've often been asked how to make userdir as a sudomain.

Maybe that can be as well in the rewrite guide.


cheers
Mario



DocumentRoot /webhosts/

[...]


ServerAlias www.example.com
ServerName www.example.com
RewriteEngine  on
RewriteCond    %{HTTP_HOST}  ^example.com
RewriteRule    ^(.*)$        /www/$1 [L]
RewriteCond    %{HTTP_HOST}  ^www.*
RewriteRule    ^(.*)$        /www/$1 [L]
RewriteCond    %{HTTP_HOST}  ^(.*)\.example\.com
RewriteRule    ^(.*)$        /%1/$1 [L]


Will be translated to

www.yourdomain.com => /webhosts/www/
muon.yourdomain.com => /webhosts/muon/

---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org

Help with rewrite rule

2009-11-05T01:59:05Z

Can someone take a look at http://httpd.apache.org/docs/trunk/rewrite/rewrite_guide.html#reverse-dynamic-mirror

  and suggest what they think this rule was intended to do? I'm  
inclined to just axe it, since no description was every provided.

--
Rich Bowen
rbowen@rcbowen.com




---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org

Re: svn commit: r832217 - in /httpd/httpd/trunk/docs/manual/rewrite: index.html.en index.xml index.xml.tr remapping.html.en remapping.xml rewrite_guide.html.en rewrite_guide.xml

2009-11-04T19:00:54Z

On Wed, Nov 4, 2009 at 1:19 PM, Rich Bowen  wrote:
> Will this fix it? :
>
>
> @@ -177,11 +177,14 @@
> �# � backward compatibility ruleset for
> �# � rewriting document.html to document.php
> �# � when and only when document.php exists
> +<Directory /var/www/htdocs>
> �RewriteEngine on
> +RewriteBase /var/www/htdocs
>
> �RewriteCond $1.php -f
> �RewriteCond $1.html !-f
> -RewriteRule ^(.*).html$ $1.php
> +RewriteRule ^(.*).html$ $1.php
> +</Directory>
> �

> � � RewriteBase is the URL-path, not the filesystem path. And I don't think test strings in a condition are expanded with respect to the base. You can figure out where the first pass landed by using %{REQUEST_FILENAME} in per-dir context: Alias /a /tmp/a RewriteBase /a RewriteEngine on # full path in per-directory contet RewriteCond %{REQUEST_FILENAME} (.*)\.html$ RewriteCond %1.php -f RewriteRule (.*)\.html$ $1.php -- Eric Covener covener@gmail.com --------------------------------------------------------------------- To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org For additional commands, e-mail: docs-help@httpd.apache.org

Re: svn commit: r832217 - in /httpd/httpd/trunk/docs/manual/rewrite: index.html.en index.xml index.xml.tr remapping.html.en remapping.xml rewrite_guide.html.en rewrite_guide.xml

2009-11-04T18:19:15Z

Will this fix it? :


@@ -177,11 +177,14 @@
  #   backward compatibility ruleset for
  #   rewriting document.html to document.php
  #   when and only when document.php exists
+<Directory /var/www/htdocs>
  RewriteEngine on
+RewriteBase /var/www/htdocs

  RewriteCond $1.php -f
  RewriteCond $1.html !-f
-RewriteRule ^(.*).html$ $1.php
+RewriteRule ^(.*).html$ $1.php
+</Directory>

On Nov 3, 2009, at 06:36 , Bob Ionescu wrote: > 2009/11/3 : >> Author: rbowen >> Date: Tue Nov 3 00:16:57 2009 >> New Revision: 832217 >> >> URL: http://svn.apache.org/viewvc?rev=832217&view=rev >> Log: >> Moves another rule out of rewrite_guide, and updates it for modern >> versions of mod_rewrite >> >> Modified: >> httpd/httpd/trunk/docs/manual/rewrite/index.html.en >> httpd/httpd/trunk/docs/manual/rewrite/index.xml >> httpd/httpd/trunk/docs/manual/rewrite/index.xml.tr >> httpd/httpd/trunk/docs/manual/rewrite/remapping.html.en >> httpd/httpd/trunk/docs/manual/rewrite/remapping.xml >> httpd/httpd/trunk/docs/manual/rewrite/rewrite_guide.html.en >> httpd/httpd/trunk/docs/manual/rewrite/rewrite_guide.xml > [... > ]> +

>> +#   backward compatibility ruleset for
>> +#   rewriting document.html to document.php
>> +#   when and only when document.php exists
>> +RewriteEngine on
>> +
>> +RewriteCond $1.php -f
>> +RewriteCond $1.html !-f
>> +RewriteRule ^(.*).html$ $1.php
>
> I think this will lead to problems since $1 should contain (in per-dir
> context) only local/foo and not /full/physical/path/to/local/foo as
> required by apr_stat().
>
> Bob
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
> For additional commands, e-mail: docs-help@httpd.apache.org
>

--
Rich Bowen
rbowen@rcbowen.com




---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org

Re: svn commit: r832310 - in /httpd/httpd/trunk/docs/manual/rewrite: remapping.html.en remapping.xml

2009-11-04T18:13:29Z

Thanks. Applied in r832826.

On Nov 3, 2009, at 06:17 , Bob Ionescu wrote:

> 2009/11/3  :
>> Author: rbowen
>> Date: Tue Nov  3 06:09:35 2009
>> New Revision: 832310
> [...]
>> -RewriteRule   ^(.*)$  ${multiplex:%1|www.example.com

>> }$1  [R,L]
>> +RewriteRule   ^(.*)$  ${multiplex:%1|http://www.example.com/

>> }$1  [R,L]
>
> I think the pattern should be ^/(.*) as well since the rule-set is
> likely placed into server context due to the map definition. So one
> will get example.com//foo or example.de//foo since both the map values
> and the default value supply the leading slash of the URL-path
> portion.
>
> Bob
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
> For additional commands, e-mail: docs-help@httpd.apache.org
>

--
Rich Bowen
rbowen@rcbowen.com




---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org

Re: svn commit: r832217 - in /httpd/httpd/trunk/docs/manual/rewrite: index.html.en index.xml index.xml.tr remapping.html.en remapping.xml rewrite_guide.html.en rewrite_guide.xml

2009-11-03T16:41:54Z


On Nov 3, 2009, at 06:36 , Bob Ionescu wrote:

>>
>> +#   backward compatibility ruleset for
>> +#   rewriting document.html to document.php
>> +#   when and only when document.php exists
>> +RewriteEngine on
>> +
>> +RewriteCond $1.php -f
>> +RewriteCond $1.html !-f
>> +RewriteRule ^(.*).html$ $1.php
>
> I think this will lead to problems since $1 should contain (in per-dir
> context) only local/foo and not /full/physical/path/to/local/foo as
> required by apr_stat().


Ah. We need a RewriteBase on there. Thanks.

--
Rich Bowen
rbowen@rcbowen.com




---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org

Re: mod_rewrite - starting to break stuff

2009-11-03T16:39:25Z


On Nov 3, 2009, at 06:32 , Dan Poirier wrote:

> Rich Bowen  writes:
>
>> I've rewritten the intro to mod_rewrite at /docs/manual/rewrite/
>> index.html  Please take a look at it and let me know what you
>> think.
>
> Reading the introduction, under "RewriteRule basics", I wonder how it
> distinguishes between the first two kinds of substitution, a  
> filesystem
> path or a web-path, since they have pretty much the same syntax.  I
> think this would be a good place for a hint about that.

Yes, I noticed that too and then forgot about it. Thanks for the  
reminder. Mostly I've been horrified at how much *completely* wrong  
stuff has been in the mod_rewrite docs for more than ten years.

--
Rich Bowen
rbowen@rcbowen.com




---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org

Re: svn commit: r832130 - in /httpd/httpd/trunk/docs/manual/mod: mod_rewrite.html.en mod_rewrite.xml

2009-11-03T14:50:40Z

2009/11/2  :
> Author: noirin
> Date: Mon Nov  2 22:05:01 2009
> New Revision: 832130
>
> URL: http://svn.apache.org/viewvc?rev=832130&view=rev
> Log:
> Ripping out the stuff that isn't really module reference, and translating the
> introduction to English
>
> Modified:
>    httpd/httpd/trunk/docs/manual/mod/mod_rewrite.html.en
>    httpd/httpd/trunk/docs/manual/mod/mod_rewrite.xml
[...]
> -Environment Variables
> -
> -      This module keeps track of two additional (non-standard)
> -      CGI/SSI environment variables named SCRIPT_URL
> -      and SCRIPT_URI. These contain the
> -      logical Web-view to the current resource, while the
> -      standard CGI/SSI variables SCRIPT_NAME and
> -      SCRIPT_FILENAME contain the physical
> -      System-view. 
> -
> -      Notice: These variables hold the URI/URL as they were
> -      initially requested, that is, before any
> -      rewriting. This is important to note because the rewriting process is
> -      primarily used to rewrite logical URLs to physical
> -      pathnames.

> -      These variables are set in per-server context, which means
> -      that they are available in per-directory context only, if
> -      RewriteEngine is set to on
in
> -      per-server context.

I think this should go somewhere else (may be env.xml?), otherwise it
is undocumented that mod_rewrite adds the special non-standard ENVs
SCRIPT_URL and SCRIPT_URI to the internal env table when used in
server context.

Bob

---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org

Re: svn commit: r832217 - in /httpd/httpd/trunk/docs/manual/rewrite: index.html.en index.xml index.xml.tr remapping.html.en remapping.xml rewrite_guide.html.en rewrite_guide.xml

2009-11-03T14:36:32Z

2009/11/3  :
> Author: rbowen
> Date: Tue Nov  3 00:16:57 2009
> New Revision: 832217
>
> URL: http://svn.apache.org/viewvc?rev=832217&view=rev
> Log:
> Moves another rule out of rewrite_guide, and updates it for modern
> versions of mod_rewrite
>
> Modified:
>    httpd/httpd/trunk/docs/manual/rewrite/index.html.en
>    httpd/httpd/trunk/docs/manual/rewrite/index.xml
>    httpd/httpd/trunk/docs/manual/rewrite/index.xml.tr
>    httpd/httpd/trunk/docs/manual/rewrite/remapping.html.en
>    httpd/httpd/trunk/docs/manual/rewrite/remapping.xml
>    httpd/httpd/trunk/docs/manual/rewrite/rewrite_guide.html.en
>    httpd/httpd/trunk/docs/manual/rewrite/rewrite_guide.xml
[...
]> +> +#   backward compatibility ruleset for
> +#   rewriting document.html to document.php
> +#   when and only when document.php exists
> +RewriteEngine on
> +
> +RewriteCond $1.php -f
> +RewriteCond $1.html !-f
> +RewriteRule ^(.*).html$ $1.php

I think this will lead to problems since $1 should contain (in per-dir
context) only local/foo and not /full/physical/path/to/local/foo as
required by apr_stat().

Bob

---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org

Re: mod_rewrite - starting to break stuff

2009-11-03T14:32:25Z

Rich Bowen  writes:

> I've rewritten the intro to mod_rewrite at /docs/manual/rewrite/
> index.html  Please take a look at it and let me know what you
> think.

Reading the introduction, under "RewriteRule basics", I wonder how it
distinguishes between the first two kinds of substitution, a filesystem
path or a web-path, since they have pretty much the same syntax.  I
think this would be a good place for a hint about that.

-- 
Dan Poirier 

---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org

Re: svn commit: r832310 - in /httpd/httpd/trunk/docs/manual/rewrite: remapping.html.en remapping.xml

2009-11-03T14:17:54Z

2009/11/3  :
> Author: rbowen
> Date: Tue Nov  3 06:09:35 2009
> New Revision: 832310
[...]
> -RewriteRule   ^(.*)$  ${multiplex:%1|www.example.com}$1
 [R,L]
> +RewriteRule   ^(.*)$  ${multiplex:%1|http://www.example.com/}$1
 [R,L]

I think the pattern should be ^/(.*) as well since the rule-set is
likely placed into server context due to the map definition. So one
will get example.com//foo or example.de//foo since both the map values
and the default value supply the leading slash of the URL-path
portion.

Bob

---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org

Re: Rewrite flags

2009-11-03T09:43:58Z

On Mon, Nov 02, 2009 at 09:19:35PM +0000, Vincent Bray wrote:
> 2009/11/2 Rich Bowen :
> > A while back I started a rewrite/flags.html doc that purported to give
> > examples for the various flag that can be used with mod_rewrite.
> >
> > Straw poll - is this
> >
> > 1) a good idea
> > 2) merely unnecessarily duplicate the contents of the reference doc, drop it
> > 3) the reference doc should simply send folks off to rewrite/flags.html for
> > further details and examples
> >
> > I'm leaning towards 2 at the moment.
> 
> Perhaps 2) but give examples of usage for popular/confusing ones elsewhere?
> 
+1 - I don't mind reference docs with good examples, but the opposite is
not a good thing.

vh

Mads Toftum
-- 
http://soulfood.dk

---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org

Re: Rewrite flags

2009-11-03T00:19:13Z


On Nov 2, 2009, at 13:19 , Vincent Bray wrote:

> 2009/11/2 Rich Bowen :
>> A while back I started a rewrite/flags.html doc that purported to  
>> give
>> examples for the various flag that can be used with mod_rewrite.
>>
>> Straw poll - is this
>>
>> 1) a good idea
>> 2) merely unnecessarily duplicate the contents of the reference  
>> doc, drop it
>> 3) the reference doc should simply send folks off to rewrite/ 
>> flags.html for
>> further details and examples
>>
>> I'm leaning towards 2 at the moment.
>
> Perhaps 2) but give examples of usage for popular/confusing ones  
> elsewhere?


Opinion seems split fairly evenly between #2 and #3 (via discussion at  
ApacheCon) and I might be leaning back towards #3. Still not sure.  
Probably won't get to this issue today anyways.

--
Rich Bowen
rbowen@rcbowen.com




---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org