PASOE / WebHandlers ... more than one cookie supported?

Posted by brianlafertewk on 23-Jan-2018 13:36

I'm working in OpenEdge 11.7.2 (on Windows) and attempting to set and get cookies using PASOE WebHandlers via REST requests (using Postman).  I put together two simple handlers maps (/MyApp/web/SetCookies and /MyApp/web/GetCookies) that respond to GET requests. 

'SetCookies' sets up three cookies (Cookie1, Cookie2, and Cookie3).  Using Postman I set the three cookies get set appropriately in the domain and path expected.

When sending a request to 'GetCookies' I am expecting to get back a JSON object with three entries (Cookie1, Cookie2, Cookie3).  Using Postman I can see that I am passing in all three cookies.  The response I get back is the first cookie only (Cookie1).  If in Postman I delete Cookie1, the response I get back will be the new first cookie (Cookie2).

For a minute I thought I could be building the response incorrectly, so I added a message statement in the logic that gets the cookies and spins through them, and only one cookie will appear in the array, no matter how many I have set.

I've tried setting the cookies simply (as the code below) and with the different security settings, all with the same result ... only the first cookie appears.  I'm seeing the same result whether I attempt this directly to the PASOE instance or using BonCode AJP13 protocol from IIS to PASOE.

Is this a bug, or am I missing something simple?  

Code sample follows.

Thanks,

Brian

  METHOD OVERRIDE PROTECTED INTEGER HandleGet( INPUT poRequest AS OpenEdge.Web.IWebRequest ):
    DEFINE VARIABLE oResponse AS OpenEdge.Net.HTTP.IHttpResponse      NO-UNDO.
    DEFINE VARIABLE oWriter   AS OpenEdge.Web.WebResponseWriter       NO-UNDO.
    DEFINE VARIABLE oBody     AS OpenEdge.Core.String                 NO-UNDO.
    DEFINE VARIABLE oCookies  AS OpenEdge.Net.HTTP.Cookie             EXTENT NO-UNDO.                       
    DEFINE VARIABLE oData     AS Progress.Json.ObjectModel.JSONObject NO-UNDO.
    DEFINE VARIABLE x         AS INTEGER                              NO-UNDO.
            
    CASE poRequest:UriTemplate:

      WHEN "/SetCookies" THEN 
        DO:
          ASSIGN 
            oResponse               = NEW OpenEdge.Web.WebResponse()
            oResponse:StatusCode    = INTEGER(StatusCodeEnum:OK)
            oBody                   = NEW OpenEdge.Core.String('[~{"msg":"cookies set"~}]')
            oResponse:Entity        = oBody
            oResponse:ContentType   = 'application/json':u
            oResponse:ContentLength = oBody:Size
            .
          oResponse:SetCookie(NEW OpenEdge.Net.HTTP.Cookie("Cookie1",'.','/',STRING(RANDOM(1,100000)))).           
          oResponse:SetCookie(NEW OpenEdge.Net.HTTP.Cookie("Cookie2",'.','/',STRING(RANDOM(1,100000)))).            
          oResponse:SetCookie(NEW OpenEdge.Net.HTTP.Cookie("Cookie3",'.','/',STRING(RANDOM(1,100000)))).            

        END.
      WHEN "/GetCookies" THEN 
        DO:
          poRequest:GetCookies(oCookies).
          
          oData = NEW Progress.Json.ObjectModel.JSONObject().
          DO x = 1 TO EXTENT(oCookies):
            oData:Add(oCookies[x]:Name, oCookies[x]:Value).
          END.

          ASSIGN 
            oResponse               = NEW OpenEdge.Web.WebResponse()
            oResponse:StatusCode    = INTEGER(StatusCodeEnum:OK)
            oResponse:Entity        = oData
            oResponse:ContentType   = 'application/json':u
            oResponse:ContentLength = LENGTH(oData:GetJsonText())
            .
        END.
        
      OTHERWISE 
      DO:
        RETURN HandleNotImplemented(poRequest).
      END.
    END CASE.            
            

    ASSIGN 
      oWriter = NEW WebResponseWriter(oResponse).
    oWriter:Open().
    oWriter:Close().
        
    RETURN 0.
    
  END METHOD. 

Posted by Peter Judge on 24-Jan-2018 08:30

Brian,
 
Looks like there are a couple of bugs in how the OE.Web.WebRequest deals with cookies how it parses them). Can you please contact TS and log a bug?
 

All Replies

Posted by Peter Judge on 24-Jan-2018 08:30

Brian,
 
Looks like there are a couple of bugs in how the OE.Web.WebRequest deals with cookies how it parses them). Can you please contact TS and log a bug?

Posted by Peter Judge on 24-Jan-2018 08:55

If you do contact TS, I've created issue PSC00363199 for this. TS can associate your company with the issue.

Posted by jankeir on 24-Jan-2018 09:58

Peter, how do you feel about porting your code to wrap libcurl and package libcurl with the openedge installation? Wouldn't that solve and avoid lots of issues? Libcurl sees so much hardening that it will always be challenging to do better.

Posted by bronco on 24-Jan-2018 10:15

[quote user="jankeir"]

Libcurl sees so much hardening that it will always be challenging to do better.

[/quote]

Couldn't agree more! My assumption is that is would give a better performance as well.

Posted by Peter Judge on 24-Jan-2018 10:18

Just a note that the webhandler/cookie issue has nothing to do with the comment that follows.. The cookie issue is just some poor ABL code.
 
 
That was one of my first thoughts (way back when). There were a couple of issue with that approach. I wanted to use libcurl, to avoid shelling out and the read/write from disk that would entail. Libcurl had some challenges. The main one relates to  POSTs (non-GET) methods. Libcurl calls GETs synchronously but POSTs are async; this means you need a callback to process the data returned by the server. While it is possible to use the libcurl DLL – and I have code that does – the ABL is not re-entrant and this meant I had to write a little C wrapper to (basically) make the POST calls synchronous/blocking. There were also issues with libcurl and writing to files on Windows.
 
This in turn means that someone has to build a DLL which the ABL can call, and this means that either we had to add libcurl into the product or you , dear customer, had to build it.  We had a similar situation with the w3c HTTP library that we use for various stuff (we needed a callback). There’s also a question with libcurl around how it integrates with (a) our message/event loop and (b) our SSL infrastructure.
 
Neither of these was a good option at the time. We do use libcurl for some of the OE Auth Gateway stuff so it may be worth revisiting.
 
 
 

Posted by brianlafertewk on 25-Jan-2018 08:58

Thank you Peter.  I submitted that case and have been told that this will be (or has been) fixed for 11.7.3. While inconvenient, we can get by until that is released.

Posted by Peter Judge on 25-Jan-2018 09:04

It has already been fixed … thanks for finding and reporting it.

Posted by jankeir on 26-Jan-2018 07:24

Glad to hear you are considering a move to libcurl. We started out using openedge.net classes for http, but moved to a custom libcurl wrapper when we needed better performance, it works and we only needed 50 lines of C code, but having stuff like this in the box would be better of course.

This thread is closed