You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Oct 2, 2024. It is now read-only.
Love the idea of an apache config file test for the apache schema! We
will have to work on this for version 5.5 though. My guess is this
shouldn't be a problem as we might have some thinking to do on this
test.
Regarding the proposed object, please note that entities in an object
can not be optional. The idea of the object is that these are the
things that are needed to uniquely identify an object. So optional
items don't really fit this bill. We are thinking about a choice
structure though for Version 6 for those objects that might be 2
different ways of uniquely identifying themselves. For example, users
can be id'd by name or SID.
Is there a known way to represent the path to a certain block
in the file? For example using slashes:
virtualserver/directory/directive. If not, maybe we can
specify one for our object. How about the following for an object:
filepath
filename
block (represented via above)
directive (this would be nilable)
This would work - it would need several capabilities:
In addition to specifying VirtualServer, you would need to specify which
VirtualServer block was of interest. This is because a single configuration
file can have multiple VirtualServer blocks and it is the parameters of the
open-tags of these blocks that differentiate them. The same would be true of
all the other blocks (File, Directory, Location, etc.)
The schema and interpreter could make no assumptions about what will be
present in a path. The block types do have a proper ordering, but as long as
the ordering is preserved, individual blocks can be present or absent from a
path. For example:
virtualserver/directory/file/
virtualserver/file/
file
directory
directory/file
All of these are legal hierarchical structures relative to the root of an
Apache file. (But "file/virtualserver" would not be allowed.) As a
corollary, the design would need to make clear whether the path
"virtualserver/file" was of equal or greater precision than the path
"file". In other words, does the path "file" mean every
file block (that met the given parameter value) in the entire config file
regardless of the presence of a parent block, or does it only match an
appropriately parameterized file block that has no parent block. There are
arguments in both directions.
The schema and interpreter would need to decide what to do with FileMatch,
DirectoryMatch, and LocationMatch blocks. These blocks are equivalent to File,
Directory, and Location blocks (respectively) but use a regular expression
pattern to specify the file/directory/URL rather than a static string.
In addition, I would suggest that a wildcard operator be valid in the path (so
you could write checks like "all virtual servers must enable X").
I don't think any of these represents a technical challenge so, in general, I
think this should work just fine. I don't know that this path structure is a
common way to refer to the hierarchical structure of an Apache file, but it
seems pretty simple and I don't think anyone would be confused by it and an
interpreter shouldn't have much trouble following it.
Please let me know if you have any questions.
Charles
The text was updated successfully, but these errors were encountered:
This would work - it would need several capabilities:
VirtualServer block was of interest. This is because a single configuration
file can have multiple VirtualServer blocks and it is the parameters of the
open-tags of these blocks that differentiate them. The same would be true of
all the other blocks (File, Directory, Location, etc.)
present in a path. The block types do have a proper ordering, but as long as
the ordering is preserved, individual blocks can be present or absent from a
path. For example:
virtualserver/directory/file/
virtualserver/file/
file
directory
directory/file
All of these are legal hierarchical structures relative to the root of an
Apache file. (But "file/virtualserver" would not be allowed.) As a
corollary, the design would need to make clear whether the path
"virtualserver/file" was of equal or greater precision than the path
"file". In other words, does the path "file" mean every
file block (that met the given parameter value) in the entire config file
regardless of the presence of a parent block, or does it only match an
appropriately parameterized file block that has no parent block. There are
arguments in both directions.
DirectoryMatch, and LocationMatch blocks. These blocks are equivalent to File,
Directory, and Location blocks (respectively) but use a regular expression
pattern to specify the file/directory/URL rather than a static string.
In addition, I would suggest that a wildcard operator be valid in the path (so
you could write checks like "all virtual servers must enable X").
I don't think any of these represents a technical challenge so, in general, I
think this should work just fine. I don't know that this path structure is a
common way to refer to the hierarchical structure of an Apache file, but it
seems pretty simple and I don't think anyone would be confused by it and an
interpreter shouldn't have much trouble following it.
Please let me know if you have any questions.
Charles
The text was updated successfully, but these errors were encountered: