php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #71717 advanced search broken
Submitted: 2016-03-05 16:48 UTC Modified: 2020-10-07 17:20 UTC
Votes:3
Avg. Score:5.0 ± 0.0
Reproduced:2 of 2 (100.0%)
Same Version:2 (100.0%)
Same OS:0 (0.0%)
From: teo8976 at gmail dot com Assigned: peehaa (profile)
Status: Assigned Package: Website problem
PHP Version: Irrelevant OS:
Private report: No CVE-ID: None
View Developer Edit
 [2016-03-05 16:48 UTC] teo8976 at gmail dot com 
Description:
------------
The advanced search page at https://bugs.php.net/search.php
is a method=GET form, yet it can generate a very large URI, causing a server error "URI Too Large".

It is inadmissible that normal use of the UI can generate a request that the same server offering the UI cannot handle.

Test script:
---------------
1. Go to https://bugs.php.net/search.php
2. In the "Return bugs from these packages" multi select, select all the items
3. Enter some keywords in the first text input field
4. hit "Search"

Expected result:
----------------
Should get the search results

Actual result:
--------------
You get a server error:
> Request-URI Too Large
> The requested URL's length exceeds the capacity limit for this server.


Suggestions: 

Either use a method=POST form, or encode the search parameters in a more efficient way.

Ah, and more importantly, test your website.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2016-04-28 20:55 UTC] teo8976 at gmail dot com 
> Also, search works fine if you choose all Top-level categories in "Return bugs 
> for these packages" while it's basically the same as selecting all the items.

Yeah, except that's a big pain in the a** having to select all of them one by one manually. It's ridiculous.


> The bug is still there but It doesn't seem to  bother anyone.

On what do you base that? On the number of complaints you [don't] receive?

Who definitely seem to not be bothered is the developers/maintainers of the website.

Come on, this is ridiculous. Switching to a POST form would be trivial!
 [2016-04-29 12:56 UTC] cmb@php.net 
Firstly, I suggest not to talk to spammers, which
"nataliepeyton332" appears to be. Can somebody with sufficient
rights please delete that comment.

Secondly, there is no need to select any package, if you want to
search for all packages.

Thirdly, feel free to submit a patch or pull request to solve the
issue.
 [2016-04-29 13:46 UTC] teo8976 at gmail dot com 
> Secondly, there is no need to select any package, if you want to
> search for all packages.

Oh, wow. Unfortunately, some category have a grey background, which makes them look like almost exactly as if they were selected by default (which in reality they aren't, they are just styled with a grey background). 

That's very confusing, making the user think that without selecting anything, those particular categories will be searched only.

Also, by selecting all top-level categories it gives LESS results than not selecting anything, which means that selecting top-level categories it does not include the subcategories automatically, so god knows what selecting top-level categories actually does (can bugs be filed within a top-level category alone without specifying any subcategory)?

The whole thing is a mess.
 [2019-12-11 15:45 UTC] peehaa@php.net
-Assigned To: +Assigned To: peehaa
 [2021-10-29 18:09 UTC] ddpm at liscovius dot de 
IMHO there are 4 steps required to solve this:

1) No second "NOT" package select.
   Reduces max GET query length from 24KB to 12KB.

2) Use p[] instead of package_name[] parameter name.
   Reduces max GET query length from 12KB to 8KB.

3) Use package_id instead of package_name for the values of the p[] select.
   Reduces max GET query length from 8K to 4 KB.
   Might also improve SQL performance for the search query if applied correctly.

4) Use a JS based auto toggling if user selects more than half of packages in the p[] select.
   Reduces max GET query length from 4KB to 2KB.


A 2KB GET query should be handled fine by browser, Apache web server, PHP and the SQL query without fiddling with web server config.


I see I joined the game of improving bugs.php.net too late as decision to shift all to github was made 5 months ago. Still resolving this with these 4 steps would improve a future readonly bugs.php.net too.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Tue Apr 01 19:01:31 2025 UTC