Last modified: 2011-11-20 11:51:26 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 3161 - Special:Export return 404 on non-existant pages
Special:Export return 404 on non-existant pages
Status: NEW
Product: MediaWiki
Classification: Unclassified
Export/Import (Other open bugs)
unspecified
All All
: Low enhancement with 2 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-08-15 21:36 UTC by Jamie Bliss
Modified: 2011-11-20 11:51 UTC (History)
2 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Patch to implement (for 1.5) (889 bytes, patch)
2005-08-15 21:39 UTC, Jamie Bliss
Details
Patch to implement (for 1.5) (707 bytes, patch)
2005-08-15 21:41 UTC, Jamie Bliss
Details
Patch to implement (for 1.5) (1.02 KB, patch)
2005-09-13 01:36 UTC, Jamie Bliss
Details
Patch to implement (for 1.5) (1.01 KB, patch)
2005-11-25 17:04 UTC, Jamie Bliss
Details

Description Jamie Bliss 2005-08-15 21:36:24 UTC
Special:Export should return a 404 if the article doesn't exist.
Comment 1 Jamie Bliss 2005-08-15 21:39:09 UTC
Created attachment 791 [details]
Patch to implement (for 1.5)

This is a patch to implement the wanted functionality. It is based off of the
current 1.5 branch (CVS v1.37 of SpecialExport.php).
Comment 2 Jamie Bliss 2005-08-15 21:41:12 UTC
Created attachment 792 [details]
Patch to implement (for 1.5)

Removed unrealated change (whitespace formatting). My bad.
Comment 3 Rowan Collins [IMSoP] 2005-08-15 22:09:53 UTC
See also bug 2585, to which I just posted a simple patch for returning 404 for
normal page and Special: page requests.

Also, why "HTTP/1.x" rather than "HTTP/1.1"?
Comment 4 Jamie Bliss 2005-08-15 22:14:05 UTC
(In reply to comment #3)
> See also bug 2585, to which I just posted a simple patch for returning 404 for
> normal page and Special: page requests.

Cool.

> Also, why "HTTP/1.x" rather than "HTTP/1.1"?

No particular reason.
Comment 5 Rowan Collins [IMSoP] 2005-08-15 22:27:30 UTC
I see no sense in which there is a "dependency" relationship between this and
bug 2585; personally, I would have treated them as the same issue, but a
cross-reference seems plenty. [Of course, if something like my patch is
implemented, Special:Export should probably use $wgOut->send404header() for
consistency; that would imply that bug 2585 blocks this rather than vice versa.]
Comment 6 Brion Vibber 2005-08-17 00:36:29 UTC
Probably better to let the export continue so the informative bits get output as expected, instead of 
a mysterious blankness.

Also a 404 might not make sense if this is a POST submission; it should probably only be done for GET 
requests where the target to load comes from the subpage suffix (Special:Export/Foobar).
Comment 7 Jamie Bliss 2005-08-17 02:39:24 UTC
(In reply to comment #6)
> Probably better to let the export continue so the informative bits get output
as expected, instead of 
> a mysterious blankness.

You could use the "-" article (since that's for generated CSS or JS) for just
informative output. (No article.) And you can still send out content with a 404
(just remove the return statement).

> Also a 404 might not make sense if this is a POST submission; it should
probably only be done for GET 
> requests where the target to load comes from the subpage suffix
(Special:Export/Foobar).

Yes and no. It may not make sense on a user post submission. If a bot was using
POST (instead of GET), it would still make perfect sense. As I said before, you
can still send content on a 404.
Comment 8 Brion Vibber 2005-08-17 03:12:14 UTC
(In reply to comment #7)
> You could use the "-" article (since that's for generated CSS or JS) for just
> informative output. (No article.) And you can still send out content with a 404
> (just remove the return statement).

Not returning any output would be a weird inconsistency, IMHO. I can't imagine any 
reason to make the choice to be inconsistent in that way; since we can return output 
with a 404 (and should, as informative output is usually expected with a 404) choosing 
not to return anything would be very unusual.

> Yes and no. It may not make sense on a user post submission. If a bot was using
> POST (instead of GET), it would still make perfect sense. As I said before, you
> can still send content on a 404.

According to my reading of the spec, a 404 response is supposed to be about the URI; 
all POSTs will be going to the same place, and it always exists, so I don't think a 
404 would ever be correct there.

  10.4.5 404 Not Found

  The server has not found anything matching the Request-URI. No
  indication is given of whether the condition is temporary or 
  permanent. ...
Comment 9 Jamie Bliss 2005-09-13 01:36:36 UTC
Created attachment 881 [details]
Patch to implement (for 1.5)

Finally fixed the two issues above.
* Return other info on 404
* Won't 404 on POST
Comment 10 Ævar Arnfjörð Bjarmason 2005-11-25 05:45:39 UTC
(In reply to comment #9)
> Created an attachment (id=881) [edit]
> Patch to implement (for 1.5)
> 
> Finally fixed the two issues above.
> * Return other info on 404
> * Won't 404 on POST

Please use proper $wgRequest wrappers for checking if the request was posted.
Comment 11 Jamie Bliss 2005-11-25 16:57:39 UTC
(In reply to comment #10)
> Please use proper $wgRequest wrappers for checking if the request was posted.

I don't remember seeing such a wrapper...

You're refering to WebRequest::wasPosted().

I'm wondering if I should actually just check if the value exists on $_GET,
since then I should return a 404 then even if it is POST.

Anyway, new patch on that coming.
Comment 12 Jamie Bliss 2005-11-25 17:04:49 UTC
Created attachment 1101 [details]
Patch to implement (for 1.5)

Defers POST detection to WebRequest. Nothing about returning 404 on POST if
article is from URI.
Comment 13 Siebrand Mazeland 2008-08-18 18:47:29 UTC
Mass compoment change: <some> -> Export/Import
Comment 14 Dan Jacobson 2009-03-17 22:15:18 UTC
All I know here in 1.15alpha, is that if I enter a hundred page names,
and even one of them is invalid, I want to see an error page
mentioning what my problem is, instead of a getting a XML download,
which is missing that one page, which I will only discover weeks
later, when I am on some mountaintop retreat with no chance of getting
the right file.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links