Wildcarded virtual path exceptions?

General discussions related to APLNext's Application and Commerce WebServices and WebTransfer product.

Moderators: Tech Support, phpbb_admin

Wildcarded virtual path exceptions?

Postby Davin Church » December 28th, 2009, 6:18 pm

I would like to assign a virtual path with a wildcard to be serviced by my APL workspace, but I would like to specify exceptions to that rule. For instance, I want /client/* to be served by my workspace but /client/images/* to be served directly by AWS without calling my workspace. (I want to keep /client/images/ as a subdirectory for web site organization purposes.)

How can I do that?
Davin Church
 
Posts: 651
Joined: February 24th, 2007, 1:46 am

Limitations of wild cards in a virtual path

Postby joe_blaze » February 1st, 2010, 6:49 pm

The server side processing of an incoming request is based upon the virtual path. This is essentially a filtering process applicable to any web server and not just APLWebServices.

So when the server receives a request to the virtual path ".../client/*", that will be filtered out and sent to the server side function associated with that virtual path. The function associated with the ".../client/images/*" virtual path will receive no 'hits' because those requests have already be filtered out by the ".../client/*" filter.

An option is to have the function associated with the ".../client/*" virtual path do additional filtering on its own. If a request comes into ".../client/*", the associated function can redirect a request of the form ".../client/images/*" to another virtual path which will serve up the images, but process other requests directly.
joe_blaze
 
Posts: 384
Joined: February 11th, 2007, 3:09 am
Location: Box 361 Brielle, NJ 08730-0361

Re: Limitations of wild cards in a virtual path

Postby Davin Church » February 1st, 2010, 7:19 pm

joe_blaze wrote:So when the server receives a request to the virtual path ".../client/*", that will be filtered out and sent to the server side function associated with that virtual path. The function associated with the ".../client/images/*" virtual path will receive no 'hits' because those requests have already be filtered out by the ".../client/*" filter.

Could I not, conceptually, list the ".../client/images/*" virtual path first and have it followed instead of the ".../client/*" path which wouldn't be encountered until later?

joe_blaze wrote:An option is to have the function associated with the ".../client/*" virtual path do additional filtering on its own. If a request comes into ".../client/*", the associated function can redirect a request of the form ".../client/images/*" to another virtual path which will serve up the images, but process other requests directly.

I'm trying to process images at high speed and redirecting every one of those requests would be excessively counter-productive. I'd prefer to not even call the APL workspace at all in order to get those files returned as fast as possible, hence my desire for WebServices to do the work for me (which it will do normally if there isn't a partially-matching virtual path).
Davin Church
 
Posts: 651
Joined: February 24th, 2007, 1:46 am

Order in which virtual paths are processed?

Postby joe_blaze » February 4th, 2010, 12:18 am

This is a worthwhile question.

We are researching if there is a way in WebServices for the programmer to specify the order in which requests to virtual paths are processed.

Under the covers, APL WebServices is a .Net assembly. That is the only way in Windows to economically implement multi-threading. The extent of programmer control over .Net certain socket functions needs to be researched further and may depend on the version of .Net on which a particular version of APL WebServices was compiled.

When results are obtained I will post them here.
joe_blaze
 
Posts: 384
Joined: February 11th, 2007, 3:09 am
Location: Box 361 Brielle, NJ 08730-0361

Re: Order in which virtual paths are processed?

Postby Davin Church » February 4th, 2010, 12:44 am

Thanks very much!

It may be worth noting that it's shouldn't be necessary to have the developer specify a particular processing order. If you process virtual paths from longest to shortest, and an "*" can only be on the end of such a path, then I think that will successfully provide for "exceptions to a general rule" without making use of a particular order.

However, the other piece to this puzzle is what to do with that "exception path" once you have it. In my case, I don't want to call a different APL function - I want it to not call my workspace at all. Instead I want it to perform "default processing" by handling the call itself (just as if it didn't match any of the virtual paths and it fell back to using real path servicing).

Perhaps that can be accomplished by leaving out the workspace and function reference, or something like that?
Davin Church
 
Posts: 651
Joined: February 24th, 2007, 1:46 am

Every virtual path must have an associated function

Postby joe_blaze » February 4th, 2010, 4:01 am

The title says it all. Since APL WebServices is modeled on Microsoft IIS, and that requirement has applied to all versions of IIS, it is not likely that it will be dropped in APL WebServices.

One alternative might be to use the WebService properties for Documents and Home Directory so put the images in there and have the virtual paths not include the home directory path.

=============

Also processing the virtual paths "longest to shortest" is a "particular processing order" which might not be ideal for some users. First we are going to identify the existing processing order and then consider if it can be made more flexible.
joe_blaze
 
Posts: 384
Joined: February 11th, 2007, 3:09 am
Location: Box 361 Brielle, NJ 08730-0361

Re: Every virtual path must have an associated function

Postby Davin Church » February 4th, 2010, 4:42 pm

joe_blaze wrote:The title says it all. Since APL WebServices is modeled on Microsoft IIS, and that requirement has applied to all versions of IIS, it is not likely that it will be dropped in APL WebServices.

I am just trying to suggest a simple way in which a "don't do this" flag could be set in APL WebServices without much coding effort. If you don't like that mechanism, then I request that you give me a way to insert a virtual-path-exemption-path, entered into a list parallel with the actual virtual paths, perhaps by using checkboxes or other methods to indicate that it's an exemption. This "exemption list" would then be checked before any virtual paths themselves to see if it should NOT be processed as a virtual path. If it is in the exemption list, then processing should continue as if it did not match any of the virtual paths.

Does that word it suitably for you to consider my request? Personally, I think that defining a normal virtual path and allowing the WSID to be left out serves as a perfectly suitable "flag" to indicate the exception status of this path, but if you don't like it then I'm not going to insist that you do it the easy way.

An alternative way to indicate an exception status (if you like it better) would be to place a boolean property in the virtual path list. When set to a 1 (conceptually a checked checkbox), it would mean that this path is an exception and it is to be processed as a REAL path instead of a virtual path. All other properties of this path (including WSID & function) would then be ignored because the virtual path is not to be processed.
Davin Church
 
Posts: 651
Joined: February 24th, 2007, 1:46 am

Postby Davin Church » February 4th, 2010, 4:47 pm

joe_blaze wrote:One alternative might be to use the WebService properties for Documents and Home Directory so put the images in there and have the virtual paths not include the home directory path.

My Home Directory contains several parallel directories. Each of those directories contains its own "image" subdirectory with images particular to that directory's application. Many of these files must have the same names across the subdirectories, but must have different contents. Therefore, they cannot be all placed in the Home Directory together.
Davin Church
 
Posts: 651
Joined: February 24th, 2007, 1:46 am

Re: Every virtual path must have an associated function

Postby Davin Church » February 4th, 2010, 6:18 pm

joe_blaze wrote:Also processing the virtual paths "longest to shortest" is a "particular processing order" which might not be ideal for some users. First we are going to identify the existing processing order and then consider if it can be made more flexible.

By "particular processing order", I thought you meant that you wanted to let the user select the order in which he wanted them processed.

If you're just selecting your own processing order, then logically you only have two choices: "longest to shortest" and "everything else". If you process them longest to shortest, that is mathematically guaranteed that all the listed possibilities are sure to be available to be processed. If you arrange the list in any other way, only two results are possible:
  1. Results are identical to processing in longest-to-shortest order
  2. A shorter path is always taken instead of a longer one, thus rendering the longer path completely "dead" and forever unusable.
Therefore, there is no possible way to order the paths that can be more or less ideal for any given user. Either all their requests can potentially be satisfied, or some of their requests (virtual paths) will be forever ignored and can simply be deleted from the list.

You could also randomize the order on every call and get a random mix of these two results, but that's ridiculous.

You could also alphabetize the paths (or use any other ordering pattern) for human readability, but make sure that shorter paths that are included as exact leading text of any longer paths always come anywhere AFTER those longer paths. However, except for human-display order, this produces results identical to strict longest-to-shortest ordering. This is probably the kind of thing you were considering, but it doesn't have any effect at all on the actual processing order.

You are perfectly welcome to continue to consider other possibilities for flexibility, but I think you'll find what I've discussed above to be invariably true. If you like, I'd be happy to discuss the logic of the above conclusions with you in more detail as part of your deliberations, but I'm convinced of their validity.
Davin Church
 
Posts: 651
Joined: February 24th, 2007, 1:46 am

Current APLWebServices Virtual Path Processing Order

Postby joe_blaze » February 13th, 2010, 7:12 am

Hi Davin,

Jairo has researched the current behavior of APLWebServices with respect to processing order of virtual paths, including those which contain wild cards and described this behavior in the attached .pdf-format document.

In this document the String.StartsWith() function is a reference to the .Net method on the String class to match an incoming string with a reference string. Note that the String.StartsWith() function is both case- and culture-sensitive. For more on this function see: http://msdn.microsoft.com/en-us/library ... swith.aspx

I checked the example provided in the .pdf-format document to assure that the behavior description is accurate.
Attachments
APLWebServices_VirtualPath_Wildcards_ProcessingOrder.pdf
APLWebServices Processing Order of Virtual Paths (including those with wildcards)
(83.39 KiB) Downloaded 628 times
joe_blaze
 
Posts: 384
Joined: February 11th, 2007, 3:09 am
Location: Box 361 Brielle, NJ 08730-0361

Re: Current APLWebServices Virtual Path Processing Order

Postby Davin Church » February 14th, 2010, 8:00 pm

Thank you, Joe. That's exactly the processing order I was talking about being most reasonable to use.

So, to get back to my original question, and assuming that it isn't already possible to perform in some way... is it feasible to add some sort of flag or condition or something to the APLWebServices system so that when a particular path is matched (when encountered in the order you've described) then APL processing will NOT be invoked (at all), the search of the remainder of the virtual path list is abandoned, and default processing will be applied (by serving up a real file name at that location instead of virtual name processing)?

It would seem to me to be easy to program (easier than what it has taken to describe it), would not affect anyone who didn't wish to use it, would not affect overall behavior or performance of APLWebServices, and would be beneficial to developers in a number of situations.

For comparison, this would be functionally similar to the Apache Web Server's RewriteRule [L] flag, where they have long recognized the need for such a capability.
Davin Church
 
Posts: 651
Joined: February 24th, 2007, 1:46 am

Postby joe_blaze » November 26th, 2010, 1:37 pm

Hi Davin,

We have not 'forgotten' about your requests for web server enhancements!

APLNext is currently testing a new Web Services product which will provide integration with Microsoft Internet Information Services (IIS). This development path has been selected rather than duplicating in an APL-based web server engine the many new features available in IIS.

The original 'stand-alone' APLNext WebServices product includes two components - a web server engine and a module to handle requests which are to be satisfied by an associated APL+Win function.

The new APLNext WebServices 'integrated with IIS' product will also include a (newly-developed) module to receive requests from IIS and satisfy them with the associated APL+Win function. However the new product relies upon an existing installation of IIS on the server machine for the web server engine component. This means that the web services programmer can take advantage of all the features of IIS and when appropriate have client service requests directed to APL+Win functions.

When this additional APLNext WebServices product becomes available (in 2011), you will be able to select the 'default behavior' of IIS whenever you deem necessary. For example, see here for the IIS re-write rule feature: http://learn.iis.net/page.aspx/460/usin ... te-module/.

APLNext will continue to maintain both WebServices products - the original 'stand-alone' APLNext WebServices' and the 'APLNext WebServices Integrated with IIS'. Thus the new product will not replace the pre-existing product and each product will be separately licensed. The APL2000 marketing staff will make it easy for a customer to switch to the new product if that request is received. The 'stand-alone' APLNext WebServices product remains useful for those programmers who do not need to utilize the extensive IIS features or who don't want to become familiar with the administration of IIS.

Here are just a few of the benefits of the APLNext WebServices 'integrated with IIS' product:
    Works with IIS 5, 6 & 7: IIS7 is noted below because Microsoft has implemented so many significant new features in this version of the product. The new APLNext WebServices 'integrated with IIS' product will also work with IIS5 and IIS6 with the availability of the respective features of each version of IIS. The Microsoft IIS product is available without charge. A version of IIS is deployable in all Windows workstation and server operating system versions since Windows 2000.

    Use Standard Ports: No need to use a separate port, now you can have APLNext WebServices using port 80 (http) or 443 (https) with IIS. You can still use a separate port if desired.

    Dynamic Caching: Using the caching feature of IIS, you can set the caching policies when serving static content. This way you don't have unnecessary load on you APL+Win sessions if the content you are proving is either static or it doesn't change all the time.

    Compression: Since IIS is now the WebServer, you can set up the IIS compression on the server side to reduce the amount of bandwidth.

    URL Rewriting: Administrators can also use URL Rewriter for IIS 7.0, which enables dynamic modification of URLs based on rules defined by the site administrator, to protect applications on the Web server. For example, rules can be created which prevent other sites from "hot-linking" to a Web site's content, thereby stealing content from the server and wasting bandwidth. Using rule templates, rewrite maps and other functionality integrated into IIS Manager, administrators can easily set up rules to define URL rewriting behavior based on HTTP headers and server variables.

    Request Filtering: IIS 7.0's Request Filtering allows administrators to implement URL acceptance polices both globally and per URL. Filtering requests helps secure the server by ensuring that only valid requests are processed. Administrators can increase Web server security by providing multiple filtering options that can prevent malicious or incorrect URLs from being processed. For example, using Request Filtering, an administrator can set a rule that prevents the display of files with certain file extensions, like .ini.

    Application Request Routing and Load Balancing: Application Request Routing (ARR) enables Web server administrators and hosting providers to increase Web application reliability and scalability through rule-based routing and load balancing of HTTP server requests. With ARR, administrators can optimize resource utilization for application servers to reduce management costs for Web farms and shared hosting environments. Up to now the only option in APLNext WebServices is to use the "busy-id".
joe_blaze
 
Posts: 384
Joined: February 11th, 2007, 3:09 am
Location: Box 361 Brielle, NJ 08730-0361


Return to APL WebServices

Who is online

Users browsing this forum: No registered users and 8 guests

cron