GET-CGI-LONG-VALUE

[GregTomkins]

Does anyone (STEFAN) know why this happens?

DEF VAR h_foo AS CHAR NO-UNDO.
DEF VAR h_bar AS LONGCHAR NO-UNDO.

/* works normally */
h_foo = WEB-CONTEXT:GET-CGI-VALUE ("ENV":U,"params") NO-ERROR.

/* returns error 'Incompatible datatypes found during runtime conversion. (5729)' */
h_bar = WEB-CONTEXT:GET-CGI-LONG-VALUE ("ENV":U,"params") NO-ERROR.

'params' is in the HTTP request, is only a few bytes, and doesn't contain anything other than normal A-Z characters. I tried fiddling with HTML-CHARSET to no avail.

The doc on GET-CGI-LONG-VALUE is sketchy, but Progress uses it like this:

FUNCTION get-cgi-long RETURNS LONGCHAR
  (INPUT p_name AS CHARACTER) :
/****************************************************************************
Description: Retrieves the LONGCHAR value for the specified CGI variable
Input Parameter: Name of variable or ?
Returns: Value or blank if invalid name.
****************************************************************************/
  IF p_name = ? THEN
    RETURN WEB-CONTEXT:GET-CGI-LIST("ENV":U).
  ELSE
    RETURN WEB-CONTEXT:GET-CGI-LONG-VALUE("ENV":U, p_name).

END FUNCTION. /* get-cgi-long */

 

[Stefan]

Not sure. Possibly the internal implementation is not as datatype loose as Progress normally is - ie if the value is not long enough it is considered a normal string which it does not want to auto-map to the longchar datatype.

Note that message string( web-context:get-cgi-long-value( "env", "remote_user" ) ) also results in the error, ruling out any issue with the longchar assignment.

 

[Stefan]

The method seems to have been introduced in 10.1A - I do wonder when anyone wants to have or access cgi variables with 32000 bytes of crud in them.

 

[GregTomkins]

Thanks for the reply. We have an IMO legit need to occasionally send 100's of K's of non-cruddy data in both directions (it's XML, so 10 bytes of actual data can easily become a TB of tag soup). It works fine server->browser ... one of the many things that drives me crazy about web development is how (unlike 4GL or C or whatever) you can never assume that data going from a->b works anything like data going b->a. But I digress.

Ws101 question, but I bet you know!: 'get-value' (etc.) is defined in cgidefs.i, and implemented in cgiutils.i. The latter is NOT included anywhere in the maze of .i's that wrapcgi.i invokes, which leads me to believe that somewhere internal to Progress it runs some .p file to preprocess web requests. Perhaps a bit like how they run the AppServer Activate procedure, except in this case the ABL is Progress-supplied (seems odd to me). Any insights appreciated, cheers from Canada.

 

[GregTomkins]

Oh, this must be it here:

srvrStartupParam=-p web/objects/web-disp.p

Thanks again for your earlier reply.

 

[Marian EDU]

Thanks for the reply. We have an IMO legit need to occasionally send 100's of K's of non-cruddy data in both directions (it's XML, so 10 bytes of actual data can easily become a TB of tag soup).

why don't you POST it as XML data then, you'll have the XML available in web context...

 

[GregTomkins]

We *do* post as XML, but it's *not* available in web-context, because the only way to get data > 32k is with get-cgi-long-value, and it's broken. I don't think web-context really knows about XML or POST vs. GET anyway.

 

[Marian EDU]

We *do* post as XML, but it's *not* available in web-context

well, I'm not saying you're not sending XML data but you're not doing it in a way the server understand what are you sending... if Content-Type header property is set to 'application/xml' then the server will know you were just sending a XML file as opposed to a bunch of name=value variables that you are retrieving now with get-value and alike.

I don't think web-context really knows about XML or POST vs. GET anyway.

sure it does, check web-context is-xml and x-document attributes

Bref, not sure how do you send the XML... might be as form post (file upload) or you have a client that makes the request or whatever. Thing is, why are you trying to use get-cgi method here? This is supposed to be used for standard cgi-bin variables, you're not going to find any files or input variables there... what you can find there is information like CONTENT_TYPE, REQUEST_METHOD and alike.

 

[GregTomkins]

Your last comment about CGI variables was correct and helpful; I confess to being confused and ill-informed about the details of CGI. Bottom line, get-long-value works fine. Thanks for your input, much appreciated.