-
Bug
-
Resolution: Won't Fix
-
Medium
-
None
-
1.3.5
-
None
I want to use this to display a list of internal build/test environments. Sometimes these are on an old old build, and sometimes they're shut down while a build is being loaded.
If I use html-include, I get "Error rendering macro: null" when the webserver is down, and when the referenced page doesn't exist, I get the contents of the webserver's 404 error.
What I'd like to be able to do is display "notfound" and "unavailable" arguments to the macro, e.g.
{html-include:url=http://todd-viegut:7001/profinia/AppInfo|notfound=old build|unavailable=site down}- is duplicated by
-
-
- Closed
-
- relates to
-
-
- Closed
-
| Form Name | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
[CONFSERVER-2909] No error handling in {html-include} macro if content is unavailable, not found or has the wrong content-type
It also fails if the Content-Type is missing, as reported in CONF-22655. I'm going to change this to be a bug.
Deleted Account (Inactive)
added a comment - Thanks for the detail; it would be nice if rather than unversioning the
issue the procedure would be to push it to the next release in cases like
this where the scope is relatively well known (and in this case the code
sounds pretty much done).
Deleted Account (Inactive)
added a comment - Thanks for the detail; it would be nice if rather than unversioning the
issue the procedure would be to push it to the next release in cases like
this where the scope is relatively well known (and in this case the code
sounds pretty much done).
While investigating this issue alongside a number of others related to the retrieval of external HTTP content, it turned out that the best solution was to have Confluence provide a generic service to perform HTTP retrieval. This would allow things like retrieval errors, HTTP-level redirects, caching and authentication to be managed in a coordinated fashion throughout all of Confluence.
Unfortunately, while most of the code for this service is written and sitting on my hard drive, it was too high-risk a change to introduce at such a late stage of the 1.4 development cycle so I had to push all the related issues back, including this one.
Tim Dawson
added a comment - this went from "easy to add" to de-listed... could you provide a reason and/or a timeframe for when it might be implemented?
Tim Dawson
added a comment - this went from "easy to add" to de-listed... could you provide a reason and/or a timeframe for when it might be implemented? Thanks for the report, this should be pretty easy to add.
Hey Tim
Thanks for taking the time to raise this issue. It looks like this hasn't been updated in quite some time, and looks to be more of a feature request rather than a bug.
Given that this issue is now 9 years old and that wiki-markup is no longer the primary method by which our users enter content into confluence I am going to close this issue out as won't fix.
If you still feel passionately about this issue I'd urge you to create a feature request to get this functionality included in confluence.
Regards
Steve Haffenden
Confluence Bugmaster
Atlassian