I'm converting an API using the Slim PHP framework to CGI. Slim handles route parameters very nicely (e.g. www.mysite.com/processorder/38929/w1?a1=test where 38929 and w1 are route parameters and includes additional GET parameters).
What is the correct or best way to do this? Do I need to configure httpd.conf to somehow convert the route parameters to POST parameters or additional GET parameters before it calls my CGI program?
I'm using the the CGIC C library at boutell.com as a starting point, if that matters.
Thanks!
Well I feel a little foolish. The answer was obvious if I had taken my head out of CGI for a second.
Since the site is served with Apache, I just needed to create an .htaccess file to convert the "route" parameters to GET parameters, including a QSA modifier to retain the original GET parameters in the URL (a1 in my example).
Related
I need to configure an apache reverse proxy to return a js script on each page. For that, I use a perl script that injects the javascript to the pages.
To do this, I used the following directive:
ExtFilterDefine fixtext mode=output intype=text/html cmd="/home/eloi/leanovia/observability/webserver-script/ttk-js-rum-injector.perl ${cookies_retrieved}"
I succeeded until this step.
However, I need to get the cookies from the request to use it in the javascript. I know I need to use expr=%{req:Cookie}
However, the expression does not evaluate when I use it like this:
ExtFilterDefine fixtext mode=output intype=text/html cmd="/home/eloi/leanovia/observability/webserver-script/ttk-js-rum-injector.perl expr=%{req:Cookie}"
I know I'm really close to the solution, but I've been struggling for hours trying to get the expression evaluated, without success. I haven't found a solution to my problem. I know that it is possible to send a header in the response that evaluates this expression, since I could test it with this directive:
Header set eloi "${cookies_retrieved}"
Try to build an API using express and was told look into URLs with the form /path/:id/extension.
The path and extension are made up, but what i was sent follows that format. I have never seen anything with the : in the route.
Can anybody interpret this and tell me what it means? Is this standard practice?
Any help would be awesome!
The :id refers to req.params() object. Effectively it is how you pass variable data, eg. you would replace :id with the specific id you are referring to in the URL path, and build your id-specific logic around it, referring to the value as req.params.id.
See the Express Documentation for more detail.
This is standard syntax does Express, the colon prefix denotes a parameter variable.
In the route handler, the URL pattern you describe would match /path/5/extension, where 5 is now accessible through req.params.id. You can read more in the ExpressJS docs under Routing.
As I understood after reading these links:
How to find out what does dispatcher cache?
http://docs.adobe.com/docs/en/dispatcher.html
The Dispatcher always requests the document directly from the AEM instance in the following cases:
If the HTTP method is not GET. Other common methods are POST for form data and HEAD for the HTTP header.
If the request URI contains a question mark "?". This usually indicates a dynamic page, such as a search result, which does not need to be cached.
The file extension is missing. The web server needs the extension to determine the document type (the MIME-type).
The authentication header is set (this can be configured)
But I want to cache url with parameters.
If I once request myUrl/?p1=1&p2=2&p3=3
then next request to myUrl/?p1=1&p2=2&p3=3 must be served from dispatcher cache, but myUrl/?p1=1&p2=2&p3=3&newParam=newValue should served by CQ for the first time and from dispatcher cache for subsequent requests.
I think the config /ignoreUrlParams is what you are looking for. It can be used to white list the query parameters which are used to determine whether a page is cached / delivered from cache or not.
Check http://docs.adobe.com/docs/en/dispatcher/disp-config.html#Ignoring%20URL%20Parameters for details.
It's not possible to cache the requests that contain query string. Such calls are considered dynamic therefore it should not be expected to cache them.
On the other hand, if you are certain that such request should be cached cause your application/feature is query driven you can work on it this way.
Add Apache rewrite rule that will move the query string of given parameter to selector
(optional) Add a CQ filter that will recognize the selector and move it back to query string
The selector can be constructed in a way: key_value but that puts some constraints on what could be passed here.
You can do this with Apache rewrites BUT it would not be ideal practice. You'll be breaking the pattern that AEM uses.
Instead, use selectors and extensions. E.g. instead of server.com/mypage.html?somevalue=true, use:
server.com/mypage.myvalue-true.html
Most things you will need to do that would ever get cached will work this way just fine. If you give me more details about your requirements and what you are trying to achieve, I can help you perfect the solution.
I need to implement a custom event handler, which should for example handle URIs like:
- SomeAppName://SomeDomainClassName/ID to fetch a record from a database table
or
- SomeAppName://SomeControllerName/PushView/SomeAdditionalOptions to push a view controller and set additional options, for example this could be a calendar view which should be focused to show the calendar at a certain date.
I have been searching for existing REST frameworks, but so far I didn't figure how any exising framework could allow me to define formats for URIs and map them to local classes, actions, whatever it will be.
How could I 1) define and interpret REST like URIs and 2) map them to local actions or objects, without reinventing the wheel (e.g. inheriting from RESTKit)?
Or should I end up to write my own parser? In that case, pointers to good REST like URI lex/flex are welcome.
What I was looking for is called an URL router in Ruby worlds. There exist a few also for Objective C, more or less useful.
I ended up to write a custom URL Router, that is like ruby URL routers just split into basically two components (router and route). For the Router part (the mapper and URL dispatcher so to say) I looked at TTURLMap, which is part of Three20, but threw away 90% of code and changed the action handling to fit my needs. It has lot's of boilerpate code, but basically was what I needed for getting an idea for the router.
For the particular route handling I use SOCKit, which seems great and has well tested code.
Now I can for example have a local function hello which takes two params to show some values passed as URL:
Roter *router = [[Router alloc] init];
[router map:#"soc://:ident/:saySomething" toInstance:self with:#selector(hello:sayWhat:)];
[router dispatch:#"soc://3/hi"];
I'll add blocks as well, but for most cases selectors work well, because SOCKit passes them the actual values for basic parameter types (no need to use parse the dictionary with values from the URL).
My Web host has refused to help me with this, so I'm coming to the wise folks here for some help "black-box debugging". Here's an edited version of what I sent to them:
I have two (among other) domains at dreamhost:
1) thefigtrees.net
2) shouldivoteformccain.com
I noticed today that when I host a CGI script on #1, that by the time the
CGI script runs, the HTTP GET query string passed to it as the QUERY_STRING
environment variable has already been URL decoded. This is a problem because
it then means that a standard CGI library (such as perl's CGI.pm) will try to
split on ampersands and then decode the string itself. There are two
potential problems with this:
1) the string is doubly-decoded, so if a value is submitted to the script
such as "%2525", it will end up being treated as just "%" (decoded twice)
rather than "%25" (decoded once)
2) (more common) if there is an ampersand in a value submitted, then it
will get (properly) submitted as %26, but the QUERY_STRING env. variable will
have it already decoded into an "&" and then the CGI library will improperly
split the query string at that ampersand. This is a big problem!
The script at http://thefigtrees.net/test.cgi demonstrates this. It echoes back the
environment variables it is called with. Navigating in a browser to:
http://thefigtrees.net/lee/test.cgi?x=y%26z
You can see that REQUEST_URI properly contains x=y%26z (unencoded) but that
QUERY_STRING already has it decoded to x=y&z.
If I repeat the test at domain #2 (
http://www.shouldivoteformccain.com/test.cgi?x=y%26z ) I see that the
QUERY_STRING remains undecoded, so that CGI.pm then splits and decodes
correctly.
I tried disabling my .htaccess files on both to make sure that was not the
problem, and saw no difference.
Could anyone speculate on potential causes of this, since my Web host seems unwilling to help me?
thanks,
Lee
I have the same behavior in Apache.
I believe mod_rewrite will automatically decode the URL if it is installed, however, I have seen the auto-decode behavior even without it. I haven't tracked down the other culprit.
A common workaround is to double encode the input parameter (taking advantage of URL decoding being safe when called on an unencoded URL).
Curious. Nothing I can see from here would give us a clue why this would happen... I can only confirm that it is an environment bug and suspect maybe configuration differences like maybe rewrite rules.
Per CGI 1.1, this decoding should only happen to SCRIPT-NAME and PATH-INFO, not QUERY-STRING. It's pointless and annoying that it happens at all, but that's the spec. Using REQUEST-URI instead of those variables where available (ie. Apache) is a common workaround for places where you want to put out-of-bounds and Unicode characters in path parts, so it might be reasonable to do the same for query strings until some sort of resolution is available from the host.
VPSs are cheap these days...