Forums | Mahara Community
Developers
/
Windows for submission problems
05 July 2009, 22:50
Hi Guys,
We are trying to make Mahara work on Windows Servers (IIS6) and have been having a few issues with some browsers that get an HTTP 303 response (IE7 & IE8 only - surprise, surprise ...).
The issue seems to be related to this particular line (the 303 will disappear when the line is uncommented):
artefact\internal\index.php
Line: 159
Solution: remove comment in line 159
$profileform = pieform(array(
'name' => 'profileform',
'plugintype' => 'artefact',
'pluginname' => 'internal',
// will be uncommented when js for tabbed interface is called again after form submit
// 'jsform' => true,
'method' => 'post',
'elements' => $elements,
'autofocus' => false,
));
I was wondering if there is any background available on why Line 159 was commented out - the descriptionin the line above is not all that clear.
Can this be changed in the release version or will it produce problems in other areas ?
Cheers,
Leo
06 July 2009, 16:18
Hi Leo,
It looks like it was Nigel who added the comment. I don't understand it either, so I'd prefer to wait till he gets back and ask him about it before we uncomment it.
09 July 2009, 21:34
Hi. I think the issue is that once you make that page into a JS form, it messes around with the javascript that converts it into a tabbed interface - or possibly vice versa. It was much easier to comment that line out.
In any event, doing that isn't really the solution. You probably actually want to fix the redirect() function, which is what issues the 303 responses. 303 is the correct response to give, so what issues are you having with ie7 and 8 exactly?
12 July 2009, 19:04
Hi Nigel,
The issue on those 2 browsers is that whenever you save the profile page IE displays a Server Error Page (due to the 303).
FF & other browsers work OK. Will have a look at the redirect()
12 July 2009, 19:34
There is also a similar error (303) on:
admin/site/options.php
This error comes from javascript page: js/adminsiteoptions.js
Line: 10
var forceReloadElements = ['sitename', 'lang', 'theme'];
Temporary fix: Change to: ==> var forceReloadElements = [];
The error seems again be caused from reloading the page in javascript. Will look at the redirect() as most likely cause.
If you have any suggestions - much appreciated.
Cheers,
Leo
12 July 2009, 21:23
Try changing it to a 302 and see if it works. If so, that will probably be the best solution - make it a 302 on IIS.14 September 2010, 1:44
Has there been any changes to this topic? Has anyone got it working?
We're using mahara 1.2.3 (2009111010), running on IIS 6, with Fastcgi.
Internet Explorer seems not to respond to status 303 messages in this case.
Editing a profile results in a connection error page, but a refresh gives the proper result.
The server logs and an http sniffer both confirm -- an /artefact/internal POST returns a 303 See Other message -- but IE doesn't do what it's supposed to which is to load the location specified in the 303.
Using Safari on windows works fine -- the logs and sniffer confirm the exact same requests/response-- but Safari follows the 303 automatically.
I tried changing to 302 as you suggested, recycled the fastcgi process -- same result. I confirmed that the 302 was being sent in the response header/logs.
I tried uncommenting the jsform-- which stuffs up the tabs, but now IE gets a 200 response on the POST, as does Safari-- which is probably meaningless because the server is returning a response rather than asking the browser to reload the page.
Thanks
14 September 2010, 2:15
I wrote a simple script to show a form, and when form is processed, if a value is set, do a 303 redirect, just to test that POST=>303=>response works. It works fine with IE -- which means it's not the redirect which is the problem, but something else.
Odd.
Any assistance much appreciated, thanks.