POST via OpenEdge.Net.HTTP - Forum - OpenEdge Deployment - Progress Community
 Forum

POST via OpenEdge.Net.HTTP

This question is answered

I'm trying to send POST via OpenEdge.Net.HTTP
(OE 11.5.1 AIX)

<Source>
DEFINE VARIABLE oRequest AS IHttpRequest NO-UNDO.
DEFINE VARIABLE oResponse AS IHttpResponse NO-UNDO.
DEFINE VARIABLE myJson AS JsonObject NO-UNDO.
...
Session:debug-alert = true.
Log-manager:logfile-name = './log.log'.

ORequest = RequestBuilder:POST (oURI, myJson)
:AcceptJson ()
:Request.

OResponse =
ClientBuilder: Build ():Client:Execute(oRequest).
OEntity = oResponse: Entity.
</ Source>

When size of myJson object is below 16384, everything is ok

When myJson is greater than 16384 the response is empty.
  -request-raw.txt is completed to 32997 by 00 (null)
  -response-data-received.txt is empty

The same POST posted by CURL reply correctly.

Which parameter is to change?

M.

Verified Answer
  • ByteBucket.cls
    Just to confirm – it’s the trailing NULLs that are causing you pain?
     
    There are a number of moving parts, but I *think* it’s a bug in the OpenEdge.Core.ByteBucket type , which is what we use to build the HTTP message before it gets written to the socket. I’ve attached a patched version – which is part of hotfixes 11.5.1.0012 and up. To test if this works, add it to an OpenEdge/Core directory that appears before $DLC/…/netlib/OpenEdge.Net.pl in PROPATH. If it does work, you should probably request (a) hotfix(es) for the relevant platforms.
     
All Replies
  • You say 'the same POST by CURL reply correctly', but it is the request actually the same sent by the HTTP Client as it is when sending it using CURL? (i.e. IIS i.e. has a default max header size of http requests of 16K)

    You can check this using a tool like i.e. Fiddler. It will record all in- and outgoing http traffic and display all information about headers/requests/responses/status codes etc etc.

  • Can you attach the request-raw.txt file?

    I'd also try checking myJson:Write(memrtVar) and/or myJson:WriteFile() to see what's output from there - that's what the HTTP client uses.

    The 11.5.1 HTTP Client was fixed/changed/improved a lot in the 11.6.0+ releases. I know it doesn't have a similar limitation.

  • details

    <source>

    ...

    DEFINE VARIABLE longCh AS LONGCHAR.

    COPY-LOB FROM FILE ".../file.json" TO longCh NO-CONVERT.

    myJson = NEW JsonObject().
    myObj = NEW JsonObject().
    myObj:ADD("name","test1").
    myJson:ADD("template",myObj).
    myJson:ADD("data",longCh).

    myObj = NEW JsonObject().
    myObj1= NEW JsonObject().

    myObj:Add("save", "true").
    myObj1:Add("reports",myObj).
    myJson:ADD("options", myObj1).

    session:debug-alert = true.
    log-manager:logfile-name = '.../log.log'.

    oRequest = RequestBuilder:POST(oURI,myJson)
    :AcceptJson()
    :Request.

    oResponse =
    ClientBuilder:Build():Client:Execute(oRequest).
    oEntity = oResponse:Entity.

    ...

    </source>

    files.zip

    on the second side, I save the pdf file

    the file is always created correctly

    M.

  • ByteBucket.cls
    Just to confirm – it’s the trailing NULLs that are causing you pain?
     
    There are a number of moving parts, but I *think* it’s a bug in the OpenEdge.Core.ByteBucket type , which is what we use to build the HTTP message before it gets written to the socket. I’ve attached a patched version – which is part of hotfixes 11.5.1.0012 and up. To test if this works, add it to an OpenEdge/Core directory that appears before $DLC/…/netlib/OpenEdge.Net.pl in PROPATH. If it does work, you should probably request (a) hotfix(es) for the relevant platforms.
     
  • it works

    thanks a lot

    M.