create new tag
, view all tags

Feature Proposal: view non-existing Topic should HTTP 302


Easier programmatic client implementation. The current situation makes it rather complicated for a programmatic client to determine whether or not a topic exists.

Description and Documentation

When viewing a non existing Topic you just get 200. Should we not rather 302 to WebTopicCreator or something like that? We do get 302 when accessing a non-existing Web.



WhatDoesItAffect: Refactoring


-- Contributors: StephaneLenclud - 09 May 2007


oh, yes please - this is probly a very simple change too - it always bugs me that my browser caches url's for non-topics (and I presume that this should be enough indicator to the browser to forget it)

I'd go so far as to call it a bug in TWiki, and to fix it - though getting other's input would make me feel safer smile

-- SvenDowideit - 09 May 2007

So I'm not the only one annoyed by that behaviour. I'd think it's not that big of a change for insiders. Might take quite a few days for me to implement though. That's why my name is not showing down there in front of CommittedDeveloper smile

-- StephaneLenclud - 10 May 2007

I am interested in that one, too. Use case: Our corporate search engine will continue forever to index topics which have been deleted, because they return a 200 status. The engine is too stupid to comprehend the topic's text smile

Implementation details:

  • Needs a new, dedicated topic to redirect to. Currently the offer to search or create the topic is shown in the contents of the response, but the body of a 302 response is irrelevant to most browsers.
  • A status 404 (Not Found) would be more correct. But browsers tend to ignore the body of a 404 response and insert their own error message, which is less useful than TWiki's offer to create the topic. So let's stick with 302, as suggested.

-- HaraldJoerg - 10 May 2007

Yes, it is useful to have an indication where machines can tell the difference. Not sure if 302 is a good choice though. From http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.3 :

The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field.

The temporary URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).

If I interpret this properly, "the temporary URI SHOULD be given by the Location field in the response" means that the browser address field would show the new URL.

-- PeterThoeny - 10 May 2007

I think there's no reasonably well supported alternative to a 302 status.

  1. "The client should continue to use the Request-URI" is fine in a Wiki world. Any topic which does not exist right now might have been created when you are looking tomorrow. Use case: "Top down" writing, where you create the links to topics while writing the summary.
  2. The Location field is part of the HTTP Header, it is just the URI to which you want to redirect. Most browsers will display this URI in their location field though they only should do that for a 301 status, but that doesn't harm: You would see a location field pointing to the new administrative view/Web/WebTopicDoesNotYetExist, with a content identical to what you get today if you view a non-existing topic.

-- HaraldJoerg - 11 May 2007

302 is wrong. 302 is used, for example, at the end of a successful save, and should not be abused as an error status; it isn't, it's a redirect. At the moment TWiki uses a 302 to redirect to an oops page, which is just lazy error handling. The oops page content should be generated by the failing script, with an appropriate error code. This is one of the reasons I created OopsException. I couldn't get rid of oops, though, because it is used for More Topic Actions, and from Func, so I gave up. frown

A 404 (or any 4xx or 5xx) status would be a big help in two cases:

  1. Where I type the URL in the browser bar. At the moment, the 302 status causes the browser to rewrite the URL to the oops page, which is a PITA if you mistyped a single character of the URL
  2. When using a script from XmlHttpRequest, where we have to jump through hoops to check error return statuses ATM

Please be really careful to test all use-cases. save and view are used in several plugins/contribs, and a change to 302 is likely to break them. I for one would strongly prefer an error status, as so much of the infrastructure is set up to deal with them. If you do have to do a 302, please add a HTTP header that returns the TWiki script status e.g. TWiki-Status: ERROR

You can use the following CGI script to test your browsers response to various status codes:

#!/usr/bin/perl -T
use CGI;
my $query = new CGI;
my $code = $query->param('code') || 200;
print CGI::header(-status => $code),"\n";
print CGI::start_html();
print "This is content generated to test status $code" if $code;
print CGI::start_form(-method => "POST",-action => $query->url());
print "Code: ".CGI::textfield(-name=> 'code', -default => $code);
print CGI::end_form(),CGI::end_html(),"\n";
I don't see any problem with using a 4xx code myself. The content I write appears as I expected.

-- CrawfordCurrie - 11 May 2007

Ok, probably you are right. It is a sad fact that browsers rewrite the URL for 302 codes though RFC2616 recommend they shouldn't. I have been distracted by MSIE, which is known to replace short server content for status 404 (and some more) by whatever it thinks is "user friendly". See http://support.microsoft.com/kb/Q294807 and http://support.microsoft.com/kb/218155/ for details. On the other hand, TWiki pages, however "short" they are for a human reader, should never fall below any reasonable threshold in the windows registry.

Hmmm..... Regarding the PITA for mistyped URLs.... Could TWiki make use of the origurl parameter, pass it to oops and so be able display the original URL in the oops page? I have been bitten by a very similar problem where a reader stumbled over an "access denied", and asking for help copypasted the oops URL which wasn't really helpful.

-- HaraldJoerg - 11 May 2007

If we add some TWiki specific status code in the HTTP response header I don't really care about the HTTP status it may as well stay 200 and thus won't break any plug-in.

I ended up opening that proposal cause there seems to be no easy way to determine programmatically whether or not a topic exists. My first thought was actually to check the HTTP response header for TWiki specifics but there was none. Then I looked at the case where you are trying to access a web that does not exists and in this case you get 302. So I thought we should be consistent and do the same for topics thus the name of the proposal. Only to say that I don't feel strong about the 302.

Adding TWiki-Status seems the best solution as it preserves the current behaviour. I'm not sure it helps HaraldJoerg with his search engine though.

-- StephaneLenclud - 11 May 2007

I think TWiki would gain by always defining a consistent TWiki-status in HTTP response header just to make it clear what the server did. Here are some of values I can think of:

  • Success
  • Not Found
  • Need Authentication
  • Access Denied

-- StephaneLenclud - 13 May 2007

I think that Harald was indicating that 404 was useable for us - but I guess someone has to code it up and try

-- SvenDowideit - 14 May 2007

Ping! Anyone interested in driving this feature?

In any case, the list of "similar topics" feature should be retained, e.g. when you type a work in the JumpBox you get a list of similar topics to chose from.

-- PeterThoeny - 2010-06-23

Edit | Attach | Watch | Print version | History: r12 < r11 < r10 < r9 < r8 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r12 - 2010-06-23 - PeterThoeny
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.