What am I misunderstanding?

AusMarkB

I am just delving into this but have tripped at the starting line.

In http_service_setup I have equated apiurl$ to 'http://localhost/e94http/OECGI4.exe/api'

I am entering this address in the browser.

http://localhost/e94http/OECGI4.exe/api/what_did_who_say

with the expectation that it would fall over but that it would return an error referring to 'what_did_who_say' not being a valid service request.

Instead I get that error but it refers to 'e94http' as the invalid service.

So what am I misunderstanding about the purpose of apiurl$ and what am I meant to be doing in order to get the NextService to begin from whatever is after 'api/'?

DonBakke

Mark,

I can't test this at the moment but I normally use (and assume) that rewrite rules are in place so that OECGI4.exe is not seen. Also, did you recompile your programs after updating this insert?

You may have very well uncovered a problem with the HTTP service. I don't think it was designed with the expectation that OECGI would be this deep into the URL. Given that this was designed with RESTful URLs in mind, it is easy for me to accept that your URL might not work out.

Please confirm the recompile issue first. If that is all good, I'll have to troubleshoot this and see if I can support the URL as you intend it to work.

AusMarkB

Don,

Yes, I recompiled.
Eventually there will be rewrite rules in place.
This was my first foray into both oecgi and your http frameworks so basically I was trying to keep things as simple as I could and just test my understanding of the concepts.

At this stage, rewrite rules appeared to be an added layer of complexity to confuse myself with.
I'm sure they're simple once you've done them a couple of times but one step at a time for me.

DonBakke

Mark,

I'll still explore this. Just out of curiosity, what web server package are you using?

AusMarkB

IIS is the answer to the question I believe you're asking.

Incidentally I've just created a rewrite rule and will test when I can get my engineserver to restart.
Am now getting an address already in use error and it just shuts straight back down.

If it's not one thing, it's another... :)

AusMarkB

So with a rewrite rule in place, this address

http://localhost/api/what_did_who_say

still returns the error from htttp_entry_services that 'e94http' is not a valid service.

So that implies to me and please correct me if I'm wrong, that the rewrite rule worked because it still converted the 'api' to the full path and fired off oecgi4.exe but the request still comes in with the full path and then starts looking for a service from the beginning.

DonBakke

Mark,

Yes, I believe the rewrite rule is working. As I had suspected, this was more of a "Hail Mary" effort on my part. The problem appears to be deeper rooted. I was able to replicate your URL and test this on my end (I also disabled rewrite just to match the original configuration).

As I contemplated your URL, I realized that e4http is really just an alternative to cgi-bin, so there is no real issue here with the depth of the path. I just so seldom see it anymore that it through me for a moment. :)

The partial good news is that my 404 error returns what I expected:

404 api is not a valid service request within the HTTP_ENTRY_POINT_SERVICES module.

I suspect the real issue is the way IIS formats the request. You can help verify my theory. Are you able to capture the incoming request and email that to me? In HTTP_MCP, there is a gosub called Debug_Tools that will capture your request and response into a designated folder. It will do this automatically if you simply create the folder (C:\xxx by default). Just shoot me the resulting text file (you can send the response if you like).

DonBakke

Mark,

Belay that request. I think I overlooked something. Let me sort this out first and I'll confirm if I want you to do anything.

AusMarkB

So the above comes into the controller routine as this:



hence the entrypoint services are trying to distribute the service 'e94http', which is understandable though from my perspective inconsistent with the example in the documentation where it is at least implied that the first service of relevance in this address 'www.myapplication.com/api/customers/5678/invoices/1234' is 'customers'.

I assume the documentation is right so I reiterate, 'what am I misunderstanding?'

AusMarkB

The partial good news is that my 404 error returns what I expected:

404 api is not a valid service request within the HTTP_ENTRY_POINT_SERVICES module.

I agree with your partial good news.
I was happy to get that error too.

..... just not so early in the chain. :)

DonBakke

Mark,

I was about to write back and and ask that you send me the request, but you just did so via the screen shot. Very good. Yes, this confirms my latest theory in that this is an IIS issue. To help explain, here is what my request looks like:

/api/what_did_who_say 0 CGI/1.1 off */* Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.116 Safari/537.36 C:\MyWebsite\www\api\what_did_who_say ::1 GET /e94http/oecgi4.exe localhost 8080 HTTP/1.1 Abyss/2.9.3.6-X1-Win32 AbyssLib/2.9.3.6

Note how my value in <2> (PATH_INFO$) only provides the path after the CGI engine. IIS, on the other hand, returns everything after the root. I am using Abyss and I believe Apache works like Abyss. However, we do have some customers using IIS so I'm trying to recall if we already encountered this and applied a work-around or if there is a configuration setting in IIS to correct this.

Hopefully Barry is monitoring this as I believe he is working with IIS and he can tell us if this was an issue in his system. I will do some research on my own. In a pinch, this can be worked around by swapping out the known parts of the path we don't want in HTTP_MCP just before the call to the SetOECGIRequest service.

BarryStevens

Mark,

>>service of relevance in this address 'www.myapplication.com/api/customers/5678/invoices/1234' is 'customers'.

the ssp name would be http_customers_services

BarryStevens

Don,

I had to do this in http_service_setup

APIURL$ = xlate("HTTP_CONFIGURATION_FILE",1,1,"X")

where the record is:
http://localhost/api

log record in <2> shows:

/funeral/16279P

when I do:
http://localhost/api/funeral/16279P

I had to make this change is http_service_setup (where you see //bsbs//)

If Assigned(Param1) then // This implies that the entry point has already been processed and the remaining URL is being processed. URLPath = Param1 If URLPath[1, 1] EQ '/' then URLPath[1, 1] = '' HTTPMethod = HTTP_Services('GetHTTPRequestMethod') NextServiceHandler = Service // The Self URL only needs to be updated if there is more URL to process. If Len(NextServiceHandler) then SelfURL = HTTP_Services('GetSelfURL') HTTP_Services('SetSelfURL', SelfURL : '/' : NextServiceHandler) end end else // This implies that the process is at the entry point. Get the full path from the request. //bsbs// ScriptName=Request<18> PathInfo=Request<2> swap ScriptName with null$ in PathInfo swap "api/" with null$ in PathInfo if pathInfo[-1,1]='/' then pathInfo[-1,1]=null$ Request<2>=PathInfo /////// URLPath = Request<2> * URLPath = HTTP_Services('GetHTTPPathInfo') If URLPath[1, 1] EQ '/' then URLPath[1, 1] = '' HTTPMethod = Request<17> // The name of this service handler can be changed if desired. NextServiceHandler = 'ENTRY_POINT' HTTP_Services('SetSelfURL', APIURL$) end

DonBakke

Barry,

Thank you for sharing this. You actually posted two things I'm presently changing in the product:

1. Storing the API path in a record rather than hard-coded in the insert (this will avoid the need to recompile so many programs).
   
2. Removing the value in SCRIPT_NAME$ out of PATH_INFO$ if it is there. This should resolve Mark's problem.
   

BarryStevens

>>
APIURL$ = xlate("HTTP_CONFIGURATION_FILE",1,1,"X")

where the record is:
http://localhost/api
<<

This had nothing to do with code problems, just testing on different servers where the address were different so it was more convenient to create record on each.

AusMarkB

Thank you Gentlemen.

Barry,

Mark,

>>service of relevance in this address 'www.myapplication.com/api/customers/5678/invoices/1234' is 'customers'.

the ssp name would be http_customers_services

Yes. Understood. What I hadn't understood was how they automatically got to the 'customers' segment of the url.
Your mod to HTTP_SERVICE_SETUP is simple enough to implement and Don's addition of the differences between IIS and ABYSS provides the why.

So I think I'm all good.

For now.

Thanks again.

DonBakke

Mark,

I intend to release an minor update a little later today. I have the changes alluded to above in place. I can't easily test the IIS fix, so I'm hoping you might do that on my behalf and report back your results. Can I send you the RDK and expect you to test it relatively soon?

AusMarkB

Spending most of the day on it today so please do.

BarryStevens

MarkB,

dont forget there are 3 places in HTTP_Entry_Point_Services that you need to put the name of your service


.
.

Case Service _EQC 'customers'
.
.


HREFNames := 'customers':@fm

.
.


HREFURIs := SelfURL : '/customers' : @FM

AusMarkB

Thanks Barry.
Hadn't forgotten.
Hadn't got that far yet. :)

Still at the front door just seeing if I can get in hence the nonsensical url 'what_did_who_say'

Now I know to keep an eye out for that though, so thanks.

DonBakke

Mark,

Do we send you RDKs in the FRAMEWORKS app or do we rekey the entities?

AusMarkB

Is FRAMEWORKS.
Is Good

AusMarkB

and that probably meant nothing to all those Non Aussies so I'll rephrase.

Yes send it as FRAMEWORKS.

Thanks.

DonBakke

Mark,

I sent off v1.0.1 RC1 to you via email. I documented the changes but I left one out. I'll note it here:

• In HTTP_MCP, the path where the request and response captures are stored is now defined in the new SRP_HTTP_FRAMEWORK_SETUP record rather than hard-coded.
  

AusMarkB

Learning lots of new stuff today :)

Barry, thought this one might be of interest to you.
I found my rewrite rule wasn't working quite the way I wanted so I started to experiment with it.
One of the things I found was that if I changed the 'Rewrite URL' value in the 'Action Properties' I could save myself a line of code. Sure it's only one line but it's a line you had to add in, that you possibly don't need any more.



Don, I'll get to testing that rdk any moment now.

AusMarkB

Looks good Don.

Am getting all the expected errors now.
Now I can start coding real questions and answers

DonBakke

Mark,

Excellent news. I'll make this update official and document the changes. Barry, I'll shoot a copy to you keyed to your app.

I also appreciate the note above regarding the Rewrite rule change. I take it you are mentioning this because the instructions posted in our blog article use the {R:0} expression. We purposely wrote that article to be as universal as possible, not assuming that any URL would have a special end point (e.g., /api). But, for those of us who are using an end point like this to distinguish between the API URLs versus the normal website URLs, the IIS configuration change is quite useful.

In my case, my Rewrite rule for Abyss already managed this properly so I never had to add the Swap statement.

AusMarkB

Yep.

I wrote my rewrite rule by blindly following the blog article making no attempt to understand.
Then I blindly followed the http frameworks documentation attempting to understand but didn't quite.
Understandably both were written based on certain assumptions. Unfortunately they were just different ones.

FWIW, in the rewrite rule I also had to add a '/' within the brackets within the Pattern.
If I didn't and my url went any longer than a single segment, then the rewrite just rewrote it to a default value on 'C:' drive and oecgi was never even nudged.

In other words, I changed the pattern from "^api/([_0-9a-z-]+)$" to "^api/([_0-9a-z-/]+)$"

Otherwise http://localhost/api/whatdidwhosay would be correctly redirected to the physical path
D:\pf\edmen94http\OECGI4.exe\whatdidwhosay

but http://localhost/api/whatdidwhosay/fox would be incorrectly redirected to

C:\inetpub\wwwroot\api\whatdidwhosay\fox

when I really want

D:\pf\edmen94http\OECGI4.exe\whatdidwhosay\fox

r.od.akker

Don, while you're at the rewriting issue; i changed my Apache rewrite rules to this:

<IfModule mod_rewrite.c> RewriteEngine on RewriteBase / RewriteRule ^v1/(.*)$ /cgi-bin/OECGI4.exe/$1 </IfModule>

The wiki links to a blog article which has this rule:

RewriteRule ^app/?([_0-9a-zA-Z-]+)$ /cgi-bin/oecgi3.exe/$1

Besides the oecgi change, I think this didn't work when your api is more than 1 level deep. So this would work: http://foo.com/app/products but this wouldn't: http://foo.com/app/products/12.

Also I'd say the query parameters won't be working, because ? and & are not included in the regexp class. I didn't test this now, but I can confirm that the new regexp seems to work fine.

JaredBratu

Thanks for pointing that out, you are right about the level depth. The original article was a simple demonstration of rewrite rules and as the HTTP Framework grew it was based off some of those rules. I checked the rules we have been deploying for the HTTP Framework and they do take into account multiple levels but that is not reflected in the blog article. I will update the blog article with a note pointing users to this list of rewrite rules specifically for the HTTP Framework.