Re: Logging the click data

[Please keep discussions on the mailing list.]

> On 17 Jun 2017, at 12:53, Vivek Pal <[email protected]> wrote:
> 
> > The only thing you cannot do is to change the HTTP status code, so you'll
> > need a new omegascript command for that. (You could probably have
> > $httpredirect{URL}, avoiding having to have a separate $httpheader{}.)
> 
> There's ShellExecute function which can potentially be used for the
> implementation of $httpredirect command but it'll only work on Windows.
> Although, I'm not aware of anything reliable similar to ShellExecute for
> UNIX based system.

No, you just need to control the first line of the HTTP response. Nothing to do with executing anything; at the moment we're using the default CGI behaviour, which is to return HTTP 200.

Thinking about this, the way that CGI works is you set a 'Status' header which changes this behaviour. So we don't actually need a new command, just something like:

$httpheader{Status,302 Found}
$httpheader{Location,$cgi{URL}}

(303 is technically the right choice rather than 302, but I can't remember offhand if there remain problems with major browsers in getting the required behaviour right.)

See http://www.oreilly.com/openbook/cgi/ch03_07.html and the parse_omegascript() function (in query.cc).

> I was wondering if it would be better to use a meta tag for redirection
> like so? <meta http-equiv="refresh" content="0.1;url=$cgi{URL}">

You can do that _as well_, but not _instead of_ the above.

> I was also wondering if there's a faster way of checking that the new
> log command works along with other changes than actually installing
> the Omega (system wide) from the branch I'm corrently working on? I
> tried doing that but messed up already running omega installation and
> had to spent almost whole yesterday just to get it back in working
> condition.

You can run omega.cgi from the command line without installing it and going via a web server. This is what the omegatests do, for instance. Once you've got it all actually working, you'll still need to test it in a web browser, of course, but it should reduce length of the development cycle.

> Also, it would be great if you could just take a quick look at the git
> diff output [2] and let me know if anything needs work.

Don't do it like this; you can open a PR and note in the comment that it isn't ready for merge, and then we get much better tools for discussing the source code.

I suggest you aim to get a PR merged with the new $qid{} command (but without using it in the default query template, since a. it should probably be a variant template, and b. you need the second template complete for it to be useful). It should be possible to review and merge $qid{} fairly quickly.

J

-- 
 James Aylett, occasional troublemaker & project governance
 xapian.org