Is it possible (and if so, how to) totally replace the output from a Special page (including the sending headers etc)?
That is, can I use a SpecialPage as a SPARQL Endpoint and have it output pure RDF/XML (or similar) if a SPARQL query is sent to it via POST, while if not, it should just display the SpecialPage including a form for submitting a SPARQL query.
Samuel
On Mon, Jun 28, 2010 at 8:19 PM, Samuel Lampa samuel.lampa.l@rilnet.comwrote:
Is it possible (and if so, how to) totally replace the output from a Special page (including the sending headers etc)?
That is, can I use a SpecialPage as a SPARQL Endpoint and have it output pure RDF/XML (or similar) if a SPARQL query is sent to it via POST, while if not, it should just display the SpecialPage including a form for submitting a SPARQL query.
It sure is! In your execute() method, you'll want to call $wgOut->disable(). This'll turn off the regular page display output at the end of request processing, and give you a chance to take over and do whatever you like, eg sending appropriate HTTP headers and output directly.
The traditional example I always like to use is Special:Export in the core code. If you bump down a bit past the initialization code and input validation, you'll see this code that's called just before we're actually doing the XML output:
if ( $this->doExport ) { $wgOut->disable(); // Cancel output buffering and gzipping if set // This should provide safer streaming for pages with history wfResetOutputBuffers(); $wgRequest->response()->header( "Content-type: application/xml; charset=utf-8" );
You should always be sure to set the content-type correctly; and if outputting XML or HTML, be sure to include a charset header.
The wfResetOutputBuffers() bit isn't required in most cases, but if you're outputting a *lot* of data it can help to let you stream output directly to the downloader. (By default, buffering is used to apply gzip encoding and send a Content-Size header. This is usually good, but means that all your output has to be built and stored in memory before it actually gets sent to the client... potentially a problem if you're streaming out fifty thousand revisions of [[Hurricane Katrina]]!)
When you're doing your raw output, you can go ahead and do 'print' or 'echo' directly if you like -- you're now in control. ;)
As a general note -- always be careful of your output to make sure you're applying proper escaping when generating HTML or XML; raw output can be a security risk if input isn't sanitized properly.
-- brion vibber (brion @ pobox.com)
Ah, there we go! :) Obviously didn't search the right places. Thanks!
Samuel
On 06/29/2010 03:07 AM, Brion Vibber wrote:
On Mon, Jun 28, 2010 at 8:19 PM, Samuel Lampasamuel.lampa.l@rilnet.comwrote:
Is it possible (and if so, how to) totally replace the output from a Special page (including the sending headers etc)?
That is, can I use a SpecialPage as a SPARQL Endpoint and have it output pure RDF/XML (or similar) if a SPARQL query is sent to it via POST, while if not, it should just display the SpecialPage including a form for submitting a SPARQL query.
It sure is! In your execute() method, you'll want to call $wgOut->disable(). This'll turn off the regular page display output at the end of request processing, and give you a chance to take over and do whatever you like, eg sending appropriate HTTP headers and output directly.
The traditional example I always like to use is Special:Export in the core code. If you bump down a bit past the initialization code and input validation, you'll see this code that's called just before we're actually doing the XML output:
if ( $this->doExport ) { $wgOut->disable(); // Cancel output buffering and gzipping if set // This should provide safer streaming for pages with history wfResetOutputBuffers(); $wgRequest->response()->header( "Content-type: application/xml;
charset=utf-8" );
You should always be sure to set the content-type correctly; and if outputting XML or HTML, be sure to include a charset header.
The wfResetOutputBuffers() bit isn't required in most cases, but if you're outputting a *lot* of data it can help to let you stream output directly to the downloader. (By default, buffering is used to apply gzip encoding and send a Content-Size header. This is usually good, but means that all your output has to be built and stored in memory before it actually gets sent to the client... potentially a problem if you're streaming out fifty thousand revisions of [[Hurricane Katrina]]!)
When you're doing your raw output, you can go ahead and do 'print' or 'echo' directly if you like -- you're now in control. ;)
As a general note -- always be careful of your output to make sure you're applying proper escaping when generating HTML or XML; raw output can be a security risk if input isn't sanitized properly.
-- brion vibber (brion @ pobox.com) _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
... and many thanks for the additional hints. Will surely come handy as the aim is to be able to use the endpoint for (batchlike) RDF export too.
Samuel
On 06/29/2010 03:07 AM, Brion Vibber wrote:
You should always be sure to set the content-type correctly; and if outputting XML or HTML, be sure to include a charset header.
The wfResetOutputBuffers() bit isn't required in most cases, but if you're outputting a*lot* of data it can help to let you stream output directly to the downloader. (By default, buffering is used to apply gzip encoding and send a Content-Size header. This is usually good, but means that all your output has to be built and stored in memory before it actually gets sent to the client... potentially a problem if you're streaming out fifty thousand revisions of [[Hurricane Katrina]]!)
When you're doing your raw output, you can go ahead and do 'print' or 'echo' directly if you like -- you're now in control.;)
As a general note -- always be careful of your output to make sure you're applying proper escaping when generating HTML or XML; raw output can be a security risk if input isn't sanitized properly.
ARC2 [0] based SPARQL Endpoint working now, as a SpecialPage, thanks to the hints. Demo: http://smwsandbox.rilspace.org/wiki/Special:SPARQLEndpoint Blog post: http://saml.rilspace.org/arc2-based-sparql-endpoint-for-semantic-mediawiki-u... Code: http://code.google.com/p/smw-rdf-connector/source/browse/#svn/trunk%3Fstate%...
Still experimental state though, and a lot of refactoring to do, so beware of ugly code. Feedback and hints are always welcome though!
Samuel
On 06/29/2010 04:32 AM, Samuel Lampa wrote:
Ah, there we go! :) Obviously didn't search the right places. Thanks!
Samuel
On 06/29/2010 03:07 AM, Brion Vibber wrote:
On Mon, Jun 28, 2010 at 8:19 PM, Samuel Lampasamuel.lampa.l@rilnet.comwrote:
Is it possible (and if so, how to) totally replace the output from a Special page (including the sending headers etc)?
That is, can I use a SpecialPage as a SPARQL Endpoint and have it output pure RDF/XML (or similar) if a SPARQL query is sent to it via POST, while if not, it should just display the SpecialPage including a form for submitting a SPARQL query.
It sure is! In your execute() method, you'll want to call $wgOut->disable(). This'll turn off the regular page display output at the end of request processing, and give you a chance to take over and do whatever you like, eg sending appropriate HTTP headers and output directly.
The traditional example I always like to use is Special:Export in the core code. If you bump down a bit past the initialization code and input validation, you'll see this code that's called just before we're actually doing the XML output:
if ( $this->doExport ) { $wgOut->disable(); // Cancel output buffering and gzipping if set // This should provide safer streaming for pages with history wfResetOutputBuffers(); $wgRequest->response()->header( "Content-type: application/xml;
charset=utf-8" );
You should always be sure to set the content-type correctly; and if outputting XML or HTML, be sure to include a charset header.
The wfResetOutputBuffers() bit isn't required in most cases, but if you're outputting a *lot* of data it can help to let you stream output directly to the downloader. (By default, buffering is used to apply gzip encoding and send a Content-Size header. This is usually good, but means that all your output has to be built and stored in memory before it actually gets sent to the client... potentially a problem if you're streaming out fifty thousand revisions of [[Hurricane Katrina]]!)
When you're doing your raw output, you can go ahead and do 'print' or 'echo' directly if you like -- you're now in control. ;)
As a general note -- always be careful of your output to make sure you're applying proper escaping when generating HTML or XML; raw output can be a security risk if input isn't sanitized properly.
-- brion vibber (brion @ pobox.com) _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
wikitech-l@lists.wikimedia.org