View Issue Details

WikiJump to Notes
IDProjectCategoryView StatusDate SubmittedLast Update
0019392mantisbtwebpagepublic2015-02-23 09:082016-09-08 08:01
ReporterMr.Bricodage Assigned To 
PrioritynormalSeverityminorReproducibilityalways
Status newResolutionopen 
Product Version1.2.19 
Summary0019392: MANTIS_BUG_LIST_COOKIE size limit
Description

Today, Mantis use the cookie named "MANTIS_BUG_LIST_COOKIE" to store on client side the last bug list filter result separated by a comma (%2C or 0x2C).
The problem occurs when user ask in GUI to list a lot of bugs in the same page. The maximum cookie size is reached and the server answer "bad request".

Cookie size limit is defined on client and server side.
On Client side, http://browsercookielimits.squawky.net/ shows that 4096 bytes is a common value for max size of all cookies in several browsers. It's a compiled value and cannot be modified using paramaters.
Even if the limit is reached on client side (cookie with more than 4096 bytes long), Mantis still works until the server limit (LimitRequestFieldSize and LimitRequestLine using Apache, default 8090 bytes) is not reached. On https://Mantisbt.org/bugs, ask for 10000 bugs on the same page to view the page "Bad request" server response that show the limit is reached on server side.
=> To use mantis again, User has to delete manually the cookie "MANTIS_BUG_LIST_COOKIE" in his browser (or cookie value size can be reduced).

Between browser limit (4096 bytes) and server limit (8090 bytes for Apache), Mantis still works even if Chrome or Firefox don't use the right cookie (cause the cookie value is truncated by browsers).

Example : if a cookie is to long, server send
Set-Cookie: MANTIS_BUG_LIST_COOKIE=1851%2C1827[...]1782%2C1806; path=/; httponly
But the cookie used by the browser is truncated in the next request :
MANTIS_BUG_LIST_COOKIE=1843%2C1827%2C1851%2C1835%2C1830%2C1854%2C1838%2C1822%2C1846[...]%2C443%

Even with the "bad" cookie, The mantis page is OK, displayed bugs are all present and not truncated with browser cookie's values.

I saw in mantisbt code that the cookie is named $g_bug_list_cookie and is used 2 times :
bug_view_inc.php (1 hit)
Line 71: $t_bugslist = gpc_get_cookie( config_get( 'bug_list_cookie' ), false );
view_all_bug_page.php (1 hit)
Line 70: gpc_set_cookie( config_get( 'bug_list_cookie' ), implode( ',', $t_bugslist ) );

My question is : is this cookie still mandatory/useful in mantis project or is it a future deprecated parameter?
It seems that the cookie value is set, but Mantis works if the value is corrupted.

Thanks in advance for your feedback, feel free to ask me questions if needed.

Steps To Reproduce

On https://Mantisbt.org/bugs, ask for 10000 bugs on the same page to view the page "Bad request" server response that show the limit is reached.
=> To use mantis again, User has to delete manually the cookie "MANTIS_BUG_LIST_COOKIE" in his browser (or cookie value size can be reduced).

Use phpinfo() or wireshark or other tool to see cookie content sent by http server and use browser cookie manager to view saved cookie.

TagsNo tags attached.
Attached Files
Capture.PNG (182,723 bytes)   
Capture.PNG (182,723 bytes)   
Capturé-2.PNG (182,723 bytes)   
Capturé-2.PNG (182,723 bytes)   

Activities

dregad

dregad

2015-02-27 04:55

developer   ~0048906

MANTIS_BUG_LIST_COOKIE is used to store the list of issues returned on a single page (in view_all_bug_page.php) by a given filter, to enable navigation between them by means of the previous/next ([<<] and [>>]) links in view.php.

By default, Mantis limits the size of list to 50 issues ($g_default_limit_view). Assuming 7 digits for bug IDs + 3 chars for the delimiter (%2C), we can "safely" handle over 400 issues in that list.

Returning 10'000 bugs in a single page seems to me like a strange thing to do. It would lead to performance issues, or even out-of-memory errors. For example, on my dev box, loading 2'000 issues required over 10s execution time, and going for 10'000 (after allocating sufficient memory to PHP) took more than 45s.

I'm wondering is your rationale / use case for returning so many issues on the view all page... If you're trying to dump a large amount of data, there are much better alternatives for that (export functions / plugins).

My question is : is this cookie still mandatory/useful in mantis project or
is it a future deprecated parameter?

There is currently no intention of changing this mechanism, which has been working well enough for many years.
Mr.Bricodage

Mr.Bricodage

2015-03-04 14:54

reporter   ~0049137

Returning 10'000 bugs in a single page seems to me like a strange thing to do.
I agree, I just gave this example to reproduice problem on your site

I'm wondering is your rationale / use case for returning so many issues on the view all page
One of my users use the view all page filter with all open bugs (1400 bugs) in the same page and use browser search capabilities to find a bug in displayed columns.

There is currently no intention of changing this mechanism, which has been working well enough for many years.
OK.

Just to inform other users :
When you use Apache as reverse proxy to access Mantis and provide a cookie with a size > 8190 bytes (something like 1400 bugs on the same page when 4 characters for bug ID), reverse proxy "cut" the transfer due to cookie size and the browser display gzipped content (as shown in provided screenshot). Tested with Chrome and Firefox.

My workaround : => To use mantis again, User has to delete manually the cookie "MANTIS_BUG_LIST_COOKIE" in his browser (or cookie value size can be reduced).

Maybe a configurable value can be used as max value for this field?
You said 400 bugs "safety", why mantis doesn't configure the max value?
administrator could modify the value but "to their own risk"...

Regards