Tuesday, May 26, 2015


I was recently asked how to successfully perform an HTTP POST request using TDI's HTTP Client Connector. NULL values kept being processed by the web server and there seemed to be no obviously documented way to perform the task.

On the face of it, this seems like a straightforward piece of functionality, but the truth is that it is not quite as straightforward as it seems.

To understand how to pass parameters to a web server via HTTP POST using TDI, it would help to understand what is actually happening when using a standard web form.

Consider the following:

<head />
<form action="result.php" method="post">
User Name<br />
<input type="text" name="uname">
<br />
Password<br />
<input type="password" name="pass">
<br />
<input type="submit" value="submit">

The submit button on this form will cause the browser to send an HTTP request to the web server with a CONTENT-TYPE of: "application/x-www-form-urlencoded". This is the key to unlocking our problem!

The values for the attributes requested in the form will be passed in the BODY of the request rather like the query string you might see in HTTP GET requests:


So to mimic form submission using the POST method via TDI, all you need to do is follow these steps:
  • Set the Mode to CallReply (if you want to see what the web server has done with your request)
  • Set the Request method to POST
  • Set the http.Content-Type to "application/x-www-form-urlencoded"
  • Set the http.body to name/value pairs in query string format

Hopefully that will see your TDI Assembly Lines behaving themselves when acting as HTTP Client and attempting to use the POST method to transfer information.

Friday, May 15, 2015

LDAP Schema Issues

It's annoying when a basic task consumes too much of your time!

Getting an LDAP Operations Error when attempting to perform an ldapmodify on an object can be irksome. It is especially irksome if the change you are making is trivial!

Consider the following object that already exists in my LDAP Server:

dn: myattr=ABC,dc=com
objectclass: top
objectclass: mycustomobject
myattr: ABC
mytrivialattribute: Z

Now consider changing that object to the following:

dn: myattr=ABC,dc=com
objectclass: top
objectclass: mycustomobject
myattr: ABC
mytrivialattribute: Y

One might reasonable expect the LDAP modify operation to be successful bearing in mind how trivial the change is. But when you get an Operations Error being thrown back at you by a hissy-fitting Directory Server, you might start to scratch your head.

The V3.modifiedschema looked perfect as mytrivialattribute was defined with a syntax of{1024}. But looking inside DB2 revealed something a little more sinister.

I followed these steps:
db2 connect to idsldap
db2 describe table idsldap.mytrivialattribute

And what I got back was:

EID with column length 4
MYTRIVIALATTRIBUTE with column length 240
RMYTRIVIALATTRIBUTE with column length 240

That didn't look right! Somehow, mytrivialattribute was created using default parameters and the V3.modifiedschema file was manually updated at a later date. As such, the database plain refused to act upon any requests to add/modify mytrivialattributes!

Getting around the problem is simple and can be done in a number of ways. I like the brutal approach though:

  • Drop the DB2 table idsldap.mytrivialattribute
  • Restart the LDAP server

Describing the table now returns:

EID with column length 4
MYTRIVIALATTRIBUTE with column length 1024
MYTRIVIALATTRIBUTE_T with column length 240
RMYTRIVIALATTRIBUTE_T with column length 240

So what was going on? Well, setting a length of 1024 on the schema definition meant that the LDAP Server wanted to put the full string into the column named MYTRIVIALATTRIBUTE and to put a truncated version of the string into MYTRIVIALATTRIBUTE_T. But the _T column didn't exist so the server couldn't perform the operation.

Dropping the table and allowing the directory server to recreate it properly on startup resolved the issue.

Of course, the ramifications now begin as to why there was a mismatch in the first place, but at least the problem has been diagnosed and rectified.