You get a proper application error so in my book no issue.

Yes, that's what I wrote with 'You get a proper page back with error message". I also explained why such a page with a 200 HTTP status code is still a problem.

Hello Carsten. That's a very good point, and you're absolutely right we should be returning a proper error code in such case.

Unfortunately this is not as easy as it sounds, given the way our error handler is written. The error code needs to be specific and meaningful, depending on the error being handled we would want a 400, 403, 404 or 500 errors (and possibly others too), so a table mapping Mantis to HTTP error codes is required.

We already have such logic in the SOAP / REST APIs (see faultFromException() function), but it would need to be adapted to core.

@dregad Thank you for your kind response.

Yes, I checked the source, too, and figured out the same.

Can we maybe apply a stupid fix?
It is basically one line of code and would only catch this common error of a non-existing issue and provide a 404 header with the normal error page.
If interested I could submit a PR on Github.

@c_schmitz contributions are always welcome, please do send the PR I will gladly review it.

Even if we merge your quick fix, I believe that a "proper", more general solution is needed anyway, as this problem of an error page returning a success code has previously hit us on several other occasions.

I had a closer look at this, and in fact it should actually be fairly simple to implement even the "proper", more general solution, i.e.

• move logic from mc_api / ApiObjectFactory::faultFromException() to a core API function
• refactor faultFromException() to use new function
• call http_response_code() with return value from new function in error_handler()

PR https://github.com/mantisbt/mantisbt/pull/2028

I just installed 2.27.0 and the issue is not fixed there. Maybe upstream merge was forgotten?

Maybe upstream merge was forgotten?

Definitely not.

$ git tag --contains 6cb11276
release-2.26.4
release-2.27.0

And as far as I can tell, it's working on this tracker, as shown in attached screenshot. Can you provide additional details ?

image.png (7,032 bytes)   

image.png (7,032 bytes)   

Hmm. check out https://bugs.limesurvey.org/view.php?id=111111111111111

After some debugging I see that in function html_end a call to fastcgi_finish_request() is made, which causes the process to be finished. (as we are using FastCGI).
So it never gets to send the header - it probably needs to be sent earlier.

Thanks for the analysis and feedback. Usage of FastCGI indeed explains the discrepancy between your system and mine.

Since the issue is fixed for "regular" CGI in 2.26.4, I will set this back to resolved, and I have opened 0034828 to track the FastCGI issue, I'll look into it as soon as possible.