WebResource : object
By default, we put all resources into the mainWebGroup object.
The point of the group is to allow different servers to use different sets of resources, or to allow one server to use different resource sets under different circumstances. When a server processes a request, it does so by looking through the 'contents' list for a group of its choice.
URL paths follow the Unix file system conventions in terms of format, but don't confuse the virtual path with an actual file system path. The vpath doesn't have anything to do with the disk file system on the server machine or anywhere else. That's why we call it "virtual" - it's merely the apparent location, from the client's perspective.
When the server receives a request from the client, it looks at the URL sent by the client to determine which WebResource object should handle the request. The server does this by matching the resource path portion of the URL to the virtual path of each WebResource, until it finds a WebResource that matches. The resource path in the URL is the part of the URL following the domain, and continuing up to but not including any "?" query parameters. The resource path always starts with a slash "/". For example, for the URL "http://192.168.1.15/test/path?param=1", the resource path would be "/test/path".
The virtual path can be given as a string or as a RexPattern. If it's a string, a URL resource path must match the virtual path exactly, including upper/lower case. If the virtual path is given as a RexPattern, the URL resource path will be matched to the pattern with the usual regular expression rules.
This method returns true if the request matches this resource, nil if not.
You can override this to specify more complex matching rules than you could achieve just by specifying the path string or RexPattern. For example, you could make the request conditional on the time of day, past request history, cookies in the request, parameters, etc.