Workaround for disabled v1 /content endpoint

[johannesloibl]

Hey there,

our IT shut down the v1 /content endpoint due to this Confluence Server bug (CONFSERVER-57639): Hitting the base Content API endpoint can cause performance problem for large instances.

I have a workaround in place using /content/scan and brute-force searching pages. You might have a look at it and decide weather it makes sense to integrate. Maybe you also know a better way to do it?

[jdknight]

Appreciate reporting this use case.

Any thoughts on having the means for the API to use GET /content/search over GET /content/scan as an alternative for GET /content calls? While CONFSERVER-57639 suggests /content/scan, first impressions are that this endpoint may be more useful when trying to query to navigate/cycle through all pages and not specifically designed for a single page fetch. With /content/search, the extension could use CQL to query for a specific page identifier and limit the search to one.

If there is something I am missing to using /content/scan over /content/search, please let me know. Either way, we can add a configuration mode which enables users to search to an alternative page search mode.

[johannesloibl]

Thanks for you response!
Actually i don't even find the API cos for GET /content/scan, but i do for GET /content/search.
I would even prefer /search since it can specifically query pages, /scan in contrast forced me to implement a brute-force approach on finding pages by name.
If /search can do it better, why not.

I'll try locally and see if the endpoint is working out, thanks for the hint ;)

[johannesloibl]

I just checked the /search endpoint and got it running. I updated the PR.
I think it's safe now to replace the current functionality with /search, since /content is deprecated anyway.

[jdknight]

@johannesloibl, appreciate the updates and the provided pull request. Decided to go with a variant (#981) due to some issues observed from testing (e.g. finding that specifying spaceId for cqlcontext did not always appear to work as expected).

The change introduces a new configuration option confluence_page_search_mode, which for your use case, you should be able to use the following to allow this extension to work in your environment:

confluence_page_search_mode = 'search'

Made this a non-default option, since /content is only deprecated for Confluence Cloud instance (from what I can tell at this time).

On a side note, it appears that CONFSERVER-57639 mainly talks about performance issues related to requests that do not use fields to limited content fetches (i.e. when trying to query all content on an instance; what the new /content/scan API attempts to support). For your DT/IT team, it may be more flexible for your userbase to only restrict GET /content calls when the parameters spaceKey and title are not provided. While I could agree that GET /content might be slower than GET /content/search due to CONFSERVER-57639, but I would be hesitant to say that GET /content/search is faster than GET /content?spaceKey=<val>&title=<val> (although, I would be interested to know if that is not the case).

[johannesloibl]

Perfectly fine for me as long I don't have to maintain the fork anymore for my company :P

[jdknight]

v2.6 is now available on PyPI -- marking as closed.

[johannesloibl]

Sorry could not test the development version yet.
But v2.6 works for me, thanks!