net.http.post/get/put – response_headers format argument

We’re doing some refactoring of the internals of some of our net.http methods.

One of the obscure response_headers argument in our net.http.post etc. methods impacts on the format of the 3rd Lua table return value which gives access to what HTTP headers came back from the response to the HTTP request.

I am curious to know to what extent people use this?

We support 3 different formats – ‘default’, ‘raw’ and ‘multiple’ and have been thinking about simplifying the choices here.

What’s the upside of simplifying the choices if the default is already the most commonly used method?

I generally prefer simplification, but not at the expense of flexibility, and I don’t find the current header format options terribly counter-intuitive. For the web services work we do, the default has so far sufficed, but I’m sure that as soon as the other options are refactored out, we’ll need them 🙂

Jeff Drumm ◊ VP and COO ◊ HICG, LLC. ◊ http://www.hicgrp.com

It helps to cut down on superfluous code if it can be done without negative impact. It makes things easier to maintain, gives more resources to functionality which helps etc.

Each little piece of superfluous code by itself doesn’t cause much of a problem but in aggregate it adds up – larger binary, more code to maintain etc.

The options for getting the headers back in my opinion would be best just default or raw – it’s very easy to split apart the raw headers. I don’t like the multiple header option I think it’s overly complicated. The options came about from an internal discussion rather than being driven by a customer request. We’re just feeling out if we can drop the ‘multiple’ option since I don’t think it’s a nice format to work with and I strongly suspect there is no code out there that uses it. So just feeling out to see if customers use it. Unless we find customers using it the next step would be to make a patch release which removes that option and gauge impact – we could put it back in again if we do find people using it – but I suspect it’s an obscure option that most people are not even aware of. I only just found out it myself recently.

The reason we are looking at this is we’re going through a process of making all the APIs in Iguana more flexible so they they can accept ‘node trees’ where previously it was required to explicitly convert things into strings so instead of having to write:

local Xml = xml.parse{data=MyXml}
// add data
net.http.post{url='http://www.acme.com', body=Xml:S()}


Instead this code could be written:

local Xml = xml.parse{data=MyXml}
// add data
net.http.post{url='http://www.acme.com', body=Xml}


The net.http.post API will be smart enough to realize that the Xml object can be converted into a string and do it for you. (it looks for a metatable that defines the __tostring function) It should make a nice subtle improvement to overall usability of the translator – especially for people that are new to Iguana and the translator.

Incidentally we have got bindings going to the Perl Compatible Regular Expression Library (PCRE) so that there are a bunch of methods like string.rxfind, string.rxmatch, string.rxsub which provide alternatives to Lua’s own built in pattern matching functions.

That along with building in the string.split function and the node.S function into the core product should give a nice bump in making the platform subtlely easier for people to use especially those that are new to Iguana – it should also make it possible to write code which looks cleaner.

Well in that case, I’m happy to lose the ‘multiple’ option to gain the functionality you describe 😀

Jeff Drumm ◊ VP and COO ◊ HICG, LLC. ◊ http://www.hicgrp.com

Thumbs up for the native node:S and string:split, and the regex implementation. Lua patterns are OK but not as powerful.

Good. The functions are already in the nightly unstable build if you want to have a look at them.

We’re putting them through QA and then the intent is to push them out in a minor point release.

Akshay has been experimenting with the capture info we get back from pcre so that you can get information on sub captures – take a look at this code:

local A=”(111,122132,231242) (112,12412,321412) (112,1134212,21231)”
for FullMatch,MatchGroups,Unmatched in A:rxfind(“(([0-9]*),([0-9]*),([0-9]*))”) do
trace(FullMatch)
trace(MatchGroups)
trace(Unmatched)
end

Currently the “MatchGroups” argument is a table which contains the sub groups matched in the regular expression.