Recent content by medu

There is a Unix/Linux shared library as well, the exe is a setup binary for Windows what is used there is also a library (DLL) but the 4gl code is same regardless of OS.

It's web-services only, to pass the SSL error you might want to add '-nohostverify' to the connection string but for office365 you need to import certificates first (look-up certutil -import).

We already have that working for office365/exchange for the following: calendar, tasks, contacts, emails and attachments (those actually can be added to practically any item in exchange)... 'one drive' (sharepoint) support for upload/download is planed to be added although authentication there...

if running on windows (and 10.2+) ews managed api is much more easy to use: http://msdn.microsoft.com/en-us/library/office/dd633709%28v=exchg.80%29.aspx

was discussed in OO info exchange in Brussels, requested to be added for all event handlers... they probably see that more as an aesthetic thing than a functional issue though :(

this is only if you send application/x-www-form-urlencoded post request (content type), normally since you send all data in XML form the content type of your request should probably be just text/xml and then the xml data can go directly into the body with no encoding - as the only 'parameter'...

you should not send that data in a GET request (parameters in query string) but as a POST, so there is no need to url-encode it

you can't use a .net ddl that way but then there is no need to either... just put that dll in the assemblies list and use it as with any other .net or progress classes. using csgDmlk.icsgDmlk. def var myDmlk as icsgDmlk. myDmlk = new icsgDmlk(). myDmlk:callFuncDmlk('toto', 'fifi'). note...

there are shared variables defined for that in cgidefs.i, you should be able to just display those with {&OUT} REQUEST_METHOD, CONTENT_TYPE this is not web-service but webspeed, you'll find more info about how things works here...

what do you get if you output the request method from cgi and content-type header?

so why do you care about the URL? just make sure you don't just stream that data back without validation... but either way, are you expecting the users to 'hack' themselves? :) point it, you need to care about user-data when and depending how you use that. you definitively shouldn't trust that...

not sure what are you after here, if looking to stripe some 'unsafe' characters from your input parameters then do that on values returned by get-value api... if you need the full list you can get it from cgi variable QUERY_STRING with get-cgi (or something like that). the full URL you need to...

If you want to have a single entry point then a proxy approach is best - for authentication, authorization, session management and those sort of things. If you have internal entries in that proxy (like in your code) then you'll waste some extra time for nothing - first run the proxy persistent...

not <string> matches <pattern>

propath separator is os dependent - for *nix think it's ':' not comma... better yet use the one that works on both nix and windows which is ';'