Item1700: manual validation confirmation fails on SSI

Currently, when a validation of a save fails, a request to manually confirm the save is returend...using a HTTP status code 401. However, in a SSI setup browsers will immediately respond on a 401 sending back their ticked or credentials, so users won't even see the confirmation dialog in the body.

Choosing the right HTTP status is not that easy here. As there was an "error" during save on behalf of the client only 4xx codes make sense. Official codes don't cover the case we have here, as far as I can see. Using an unofficial among the 41x codes might clash with sub codes used by M$.

To make normal interaction work again, there is not much choice but sending a 200 Ok again. Bad news for those that used save via an ajax call.

Any better idea?

---

That's even worse than that, because with ApacheLogin, 401 should trigger the Registration page, and the user might never see the page.

We discussed this with Crawford, and we agreed that there isn't any numeric for that, so we could use a new 4xx.

-- OlivierRaginel - 09 Jun 2009

Which one?

-- MichaelDaum - 09 Jun 2009

Please remember that this must be fixed in both trunk and Release branch. I will port the fix now to test it. I am testing heavily at the moment.

-- KennethLavrsen - 09 Jun 2009

I have not seen any negative effects of Michael's change to a normal 200.

Can we close this one now?

Do we have a solution for the rest case?

-- KennethLavrsen - 14 Jun 2009

What rest case?

REST handlers are able to specify the exit code. They are also able to enable/disable validation selectively. Not sure what more we can do.

-- CrawfordCurrie - 15 Jun 2009

Changed the code to 419 - it is now officially Crawford's fault. I am innocent

No - we need to test it so I checked in the 419.

Setting to Closed. Reopen if something fails.

-- KennethLavrsen - 16 Jun 2009