Document Litespeed SAPI functions

[AllenJB]

Related: #2163

This requires an additional change to doc-base/manual.xml to reference the new book.

(How does the above mentioned change work with regards to translations? Would this PR need to wait for all translations to implement the new book?)

While technically the opposite way round (according to the php-src stubs), I've documented these as aliases for the apache_* functions where appropriate - seems like the simplest way to implement this.

[lacatoire]

This PR adds "LiteSpeed" to apache_request_headers and apache_response_headers, nice! But it looks like getallheaders.xml could use the same treatment, since it's also available under the LiteSpeed SAPI.

In php-src, getallheaders is registered as an alias of litespeed_request_headers:

• Current stub
• Generated arginfo

Would it make sense to update getallheaders.xml as well in this PR? 😊

[AllenJB]

But it looks like getallheaders.xml could use the same treatment, since it's also available under the LiteSpeed SAPI.

Would it make sense to update getallheaders.xml as well in this PR? 😊

I don't think so. The getallheaders() page already redirects users to the apache_request_headers() documentation (which I have updated) and doesn't currently mention SAPI availability.

Adding the same information on the getallheaders() page directly would just be unnecessary duplication.

[jordikroon]

This requires an additional change to doc-base/manual.xml to reference the new book.

This change has been done. Could you rebase this PR so it will trigger a new CI workflow?

(How does the above mentioned change work with regards to translations? Would this PR need to wait for all translations to implement the new book?)

It's perfectly fine to open a PR for the required change. It's usually a no-brainer to hit the merge button as they are just references. We don't need to wait for other languages to implement this book. As a matter of fact, it's quite the opposite. Once this is merged, it allows other languages to adopt this.

While technically the opposite way round (according to the php-src stubs), I've documented these as aliases for the apache_* functions where appropriate - seems like the simplest way to implement this.

That seems very logical. I will do a review later. Just a quick glimpse; could you change <para> to <simpara> where possible? This will save a lot of comments that will otherwise clutter the PR anyway.

[lacatoire]

Suggested change

	<member><function>apache_response_headers</function></member>
	<member><function>litespeed_request_headers</function></member>
	<member><function>getallheaders</function></member>

[jordikroon]

I have not suggested the <simpara> but there are still a few that Lacatoire didn't mention. It would only add more comments making it harder to go over all the changes.

Overall this looks very good.

[alfsb]

This requires an additional change to doc-base/manual.xml to reference the new book.

(How does the above mentioned change work with regards to translations? Would this PR need to wait for all translations to implement the new book?)

In general, adding new files does not break translations. If doc-en builds, then there is a chance that translations keep working. But there some (even, many) cases where a breaking change is inevitable, sadly.

Also, having doc-base/manual.xml outside doc-en means that structure changing PRs are not "atomic", and so, it's impossible to CI test doc-en, and less so all translations.

[jordikroon]

Small nit. Other than that LGTM.

[jordikroon]

Thank you!