Feature Proposal: Adding the script and uri to the header on a reponse help a lot when using asynchronous ajax calls

Motivation

To upgrade Foswiki to use a lot of web 2.0 techniques, we need a proper core support for such asynchronous calls.

One big problem is, that when you fetch data from a url, you never now, who will return the fetched data. It could happen a redirect you will never now from, which returns you the login form instead of the edit or attach from..

Description and Documentation

When using Ajax calls, and you e.g. fetch the attach form and you want to display this in a dialog, 400x400. But suddenly your request gets redirected and you get the loginform returned. The login form is normally shown in a 200x200 dialog. Or for example, you instead get returned a view of a topic, because you got redirected. You would then show a huge topic, with the whole layout, in a small dialog.

When you know, which script returned the fetched data, you can handle this on client side, resize the dialog ( by the handler for login-scripts ) or close the dialog on set document.location to the uri of view ( by the view handler ).

Setting the X-Action and X-Uri fields in the header would not break anything(talked to some apache devs and looked at the RFC) and can be done by a 2liner in the UI.pm::execute. X- stands for "custom header" and that RFC conform.

I have tested this and it yet work. I can think about a problem field, where the client uses the maximum size of the header the server defines, by use GET. It could work yet, as lets say he filled up 100% and it ( by accident ) work, but now it would break. Iam not sure we have something on any places, because this is bad by design and thats what POST is for.

• I think you're confusing GET / POST requests with reponse headers. Here, from what I've understood, you're adding 2 fields to the response header. The problem with the GET / POST is when you're submitting a form by GET, all parameters get appended to the URI, which is limited in size. The headers are not (afaik) limited at all. Some partts are: See the apache documentation for example. The only issue I can think about is that you are exposing some internal things to the client, which could cause some security issue. But considering what you're exposing, I doubt it's a big deal. -- OlivierRaginel - 01 Feb 2009

Examples

The Extensions.JQueryCompatibilityModePlugin implements an dialogAPI using this approach. Here is the small code using it /trac): trac-link

Impact

WhatDoesItAffect:

%WHATDOESITAFFECT%

edit

Implementation

-- Contributors: EugenMayer - 20 Jan 2009

Discussion

Instead of forcing the release branch now I agree with Eugen to check in the two liner in trunk and include it in 1.0.1.

If you oppose this move which is an exception to the normal rule - shout - and we revert

-- KennethLavrsen - 31 Jan 2009

i think this is a good thing to accept into 1.0.1, and better to check in sooner with more time for testing than later.

-- WillNorris - 31 Jan 2009

This was implemented and accepted by 14 day rule.

-- KennethLavrsen - 21 Mar 2009