You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by "Alexander Dutton (Created) (JIRA)" <ji...@apache.org> on 2012/03/08 23:13:58 UTC

[jira] [Created] (JENA-218) Fuseki should allow timeouts to be specified on a per-request basis

Fuseki should allow timeouts to be specified on a per-request basis
-------------------------------------------------------------------

                 Key: JENA-218
                 URL: https://issues.apache.org/jira/browse/JENA-218
             Project: Apache Jena
          Issue Type: Improvement
          Components: Fuseki
    Affects Versions: Fuseki 0.2.1
            Reporter: Alexander Dutton


A query endpoint might want to have different timeouts depending on whether queries are from untrusted or trusted users, or maintenance processes. The timeout could be passed with an X- header, a Timeout header as per http://tools.ietf.org/html/draft-loreto-http-timeout-00, or a query parameter, respecting the system default if none is provided. The query parameter might be less favourable as it'd be harder to filter out for Fuseki instances behind Apache.

There is a risk that changing the behaviour to allow timeouts to be overridden will lead to DoSs of query endpoints open to the world to some extent. This can be mitigated by defaulting to disallowing timeout overrides.

I'm happy to put a patchdocu together and document it at http://incubator.apache.org/jena/documentation/serving_data/.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Updated] (JENA-218) Fuseki should allow timeouts to be specified on a per-request basis

Posted by "Alexander Dutton (Updated) (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/JENA-218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexander Dutton updated JENA-218:
----------------------------------

    Attachment: config-tdb.ttl
                jena-218-1.diff

First go at a patch, and a config file that enables the new functionality. I've got SPARQL_ServletBase passing a DatasetRef in place of a DatasetGraph to perform (though the default implementation calls perform with the previous signature for compatibility).
The reporting of the length of the timeout when returning the 408 is currently wrong, as it doesn't take into account any user-provided timeout. I'm not quite sure of the best way to get the actual timeout into the right place without changing rather a lot (one would be to include the QueryExecution or timeout value as a member of the QueryExecutionCancelled exception).
Still got to work on the documentation. Do we need tests?
                
> Fuseki should allow timeouts to be specified on a per-request basis
> -------------------------------------------------------------------
>
>                 Key: JENA-218
>                 URL: https://issues.apache.org/jira/browse/JENA-218
>             Project: Apache Jena
>          Issue Type: Improvement
>          Components: Fuseki
>    Affects Versions: Fuseki 0.2.1
>            Reporter: Alexander Dutton
>              Labels: needsdocumentation, timeout
>         Attachments: config-tdb.ttl, jena-218-1.diff
>
>
> A query endpoint might want to have different timeouts depending on whether queries are from untrusted or trusted users, or maintenance processes. The timeout could be passed with an X- header, a Timeout header as per http://tools.ietf.org/html/draft-loreto-http-timeout-00, or a query parameter, respecting the system default if none is provided. The query parameter might be less favourable as it'd be harder to filter out for Fuseki instances behind Apache.
> There is a risk that changing the behaviour to allow timeouts to be overridden will lead to DoSs of query endpoints open to the world to some extent. This can be mitigated by defaulting to disallowing timeout overrides.
> I'm happy to put a patch together and document it at http://incubator.apache.org/jena/documentation/serving_data/.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Updated] (JENA-218) Fuseki should allow timeouts to be specified on a per-request basis

Posted by "Alexander Dutton (Updated) (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/JENA-218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexander Dutton updated JENA-218:
----------------------------------

    Attachment:     (was: jena-218-1.diff)
    
> Fuseki should allow timeouts to be specified on a per-request basis
> -------------------------------------------------------------------
>
>                 Key: JENA-218
>                 URL: https://issues.apache.org/jira/browse/JENA-218
>             Project: Apache Jena
>          Issue Type: Improvement
>          Components: Fuseki
>    Affects Versions: Fuseki 0.2.1
>            Reporter: Alexander Dutton
>              Labels: needsdocumentation, timeout
>         Attachments: config-tdb.ttl, jena-218-1.diff
>
>
> A query endpoint might want to have different timeouts depending on whether queries are from untrusted or trusted users, or maintenance processes. The timeout could be passed with an X- header, a Timeout header as per http://tools.ietf.org/html/draft-loreto-http-timeout-00, or a query parameter, respecting the system default if none is provided. The query parameter might be less favourable as it'd be harder to filter out for Fuseki instances behind Apache.
> There is a risk that changing the behaviour to allow timeouts to be overridden will lead to DoSs of query endpoints open to the world to some extent. This can be mitigated by defaulting to disallowing timeout overrides.
> I'm happy to put a patch together and document it at http://incubator.apache.org/jena/documentation/serving_data/.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Commented] (JENA-218) Fuseki should allow timeouts to be specified on a per-request basis

Posted by "Andy Seaborne (Commented) (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/JENA-218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13226000#comment-13226000 ] 

Andy Seaborne commented on JENA-218:
------------------------------------

This would be great.  

I'd like to see at least ?timeout= form for pragmatic reasons. This makes it similar to other systems.  It's much easier to set in the client where access to setting the HTTP headers can be tricky (e.g. when using a library for HTTP calls, not going raw to java.net or Apache httpClient).  When writing a call, whether scripting or java, it's easier to do everything in the query string but a sem-standard is also 

Having header and query parameter is possible - it's not either/or.

The DoS issue is a serious one, I think.  From just looking at usage (e.g. DBPedia), people override the timeout as the first "solution" to a query timing out when the query is just inherently expensive and missing the timeout by a long way.  As a usage is public-facing data serving is one use for Fuseki, armour-plating the timeout mechanism is required.

A complicated scheme is to have a second timeout associated with the dataset that is the maximum allowable settings.  If absent, any normal timeout set should be the maximum allowed.  Setting the max setting very high (or, better, a special value) would be the same as letting the client take full control.  Absence, or setting the same as the normal timeout is, in effect, no override as you can only set it shorter but a special value for "not allowed" would make for a better error message like "You can't do that".
                
> Fuseki should allow timeouts to be specified on a per-request basis
> -------------------------------------------------------------------
>
>                 Key: JENA-218
>                 URL: https://issues.apache.org/jira/browse/JENA-218
>             Project: Apache Jena
>          Issue Type: Improvement
>          Components: Fuseki
>    Affects Versions: Fuseki 0.2.1
>            Reporter: Alexander Dutton
>              Labels: needsdocumentation, timeout
>
> A query endpoint might want to have different timeouts depending on whether queries are from untrusted or trusted users, or maintenance processes. The timeout could be passed with an X- header, a Timeout header as per http://tools.ietf.org/html/draft-loreto-http-timeout-00, or a query parameter, respecting the system default if none is provided. The query parameter might be less favourable as it'd be harder to filter out for Fuseki instances behind Apache.
> There is a risk that changing the behaviour to allow timeouts to be overridden will lead to DoSs of query endpoints open to the world to some extent. This can be mitigated by defaulting to disallowing timeout overrides.
> I'm happy to put a patch together and document it at http://incubator.apache.org/jena/documentation/serving_data/.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Commented] (JENA-218) Fuseki should allow timeouts to be specified on a per-request basis

Posted by "Alexander Dutton (Commented) (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/JENA-218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13226017#comment-13226017 ] 

Alexander Dutton commented on JENA-218:
---------------------------------------

Yes, supporting both headers and query parameters sounds sensible. If both are specified, shall we take the minimum? Taking the minimum woud allow e.g. httpd to add a Timeout header for unauthed users, which restricts timeouts, but does not take away the user's freedom to specify a lower timeout.

So, the config could be something like:

<#service3>  rdf:type fuseki:Service ;
    fuseki:name              "tdb" ;       # http://host:port/tdb
    fuseki:serviceQuery      "sparql" ;    # SPARQL query service
    fuseki:allowTimeoutOverride true ;
    fuseki:maximumTimeoutOverride 4 ;
    fuseki:dataset           <#dataset> .

If allowTimeoutOverride isn't specified we default to leaving it disabled (hence, backwards compatibility with current behaviour), and if maximumTimeoutOverride is missing, default to allowing unlimited timeouts (the documentation can suggest that you probably want to specify both together. Do we want this specified in seconds or milliseconds?

I would argue that it should silently ignore attempts to set a timeout when none is allowed, lest a client is optimistically asking timeouts of everything it queries and gets confused by a 400 or 501.
                
> Fuseki should allow timeouts to be specified on a per-request basis
> -------------------------------------------------------------------
>
>                 Key: JENA-218
>                 URL: https://issues.apache.org/jira/browse/JENA-218
>             Project: Apache Jena
>          Issue Type: Improvement
>          Components: Fuseki
>    Affects Versions: Fuseki 0.2.1
>            Reporter: Alexander Dutton
>              Labels: needsdocumentation, timeout
>
> A query endpoint might want to have different timeouts depending on whether queries are from untrusted or trusted users, or maintenance processes. The timeout could be passed with an X- header, a Timeout header as per http://tools.ietf.org/html/draft-loreto-http-timeout-00, or a query parameter, respecting the system default if none is provided. The query parameter might be less favourable as it'd be harder to filter out for Fuseki instances behind Apache.
> There is a risk that changing the behaviour to allow timeouts to be overridden will lead to DoSs of query endpoints open to the world to some extent. This can be mitigated by defaulting to disallowing timeout overrides.
> I'm happy to put a patch together and document it at http://incubator.apache.org/jena/documentation/serving_data/.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Assigned] (JENA-218) Fuseki should allow timeouts to be specified on a per-request basis

Posted by "Andy Seaborne (Assigned) (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/JENA-218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andy Seaborne reassigned JENA-218:
----------------------------------

    Assignee: Andy Seaborne
    
> Fuseki should allow timeouts to be specified on a per-request basis
> -------------------------------------------------------------------
>
>                 Key: JENA-218
>                 URL: https://issues.apache.org/jira/browse/JENA-218
>             Project: Apache Jena
>          Issue Type: Improvement
>          Components: Fuseki
>    Affects Versions: Fuseki 0.2.1
>            Reporter: Alexander Dutton
>            Assignee: Andy Seaborne
>              Labels: needsdocumentation, timeout
>         Attachments: config-tdb.ttl, jena-218-1.diff
>
>
> A query endpoint might want to have different timeouts depending on whether queries are from untrusted or trusted users, or maintenance processes. The timeout could be passed with an X- header, a Timeout header as per http://tools.ietf.org/html/draft-loreto-http-timeout-00, or a query parameter, respecting the system default if none is provided. The query parameter might be less favourable as it'd be harder to filter out for Fuseki instances behind Apache.
> There is a risk that changing the behaviour to allow timeouts to be overridden will lead to DoSs of query endpoints open to the world to some extent. This can be mitigated by defaulting to disallowing timeout overrides.
> I'm happy to put a patch together and document it at http://incubator.apache.org/jena/documentation/serving_data/.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Commented] (JENA-218) Fuseki should allow timeouts to be specified on a per-request basis

Posted by "Alexander Dutton (Commented) (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/JENA-218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13249610#comment-13249610 ] 

Alexander Dutton commented on JENA-218:
---------------------------------------

1/ WRT HTTP headers, one could extend the Timeout header to take both timeouts, but that's liable to encourage people to send two timeouts to other SPARQL services. We could take note of a Fuseki-specific header (e.g. X-Fuseki-Timeout), which will allow both to be set.

2/ Quite possibly, yes. It'd be a bit more forgiving.

3/ I standardised on seconds between the config, parameter and header as the Timeout header is specified in seconds. Would it be confusing to have the config (internal) be milliseconds, and the HTTP-based stuff (external) be seconds? Changing arq:queryTimeout to be in seconds would be rather backwards-incompatible at this stage, wouldn't it? (Unless jena-dev says that no one sets the timeout in that manner…)
                
> Fuseki should allow timeouts to be specified on a per-request basis
> -------------------------------------------------------------------
>
>                 Key: JENA-218
>                 URL: https://issues.apache.org/jira/browse/JENA-218
>             Project: Apache Jena
>          Issue Type: Improvement
>          Components: Fuseki
>    Affects Versions: Fuseki 0.2.1
>            Reporter: Alexander Dutton
>            Assignee: Andy Seaborne
>              Labels: needsdocumentation, timeout
>         Attachments: config-tdb.ttl, jena-218-1.diff
>
>
> A query endpoint might want to have different timeouts depending on whether queries are from untrusted or trusted users, or maintenance processes. The timeout could be passed with an X- header, a Timeout header as per http://tools.ietf.org/html/draft-loreto-http-timeout-00, or a query parameter, respecting the system default if none is provided. The query parameter might be less favourable as it'd be harder to filter out for Fuseki instances behind Apache.
> There is a risk that changing the behaviour to allow timeouts to be overridden will lead to DoSs of query endpoints open to the world to some extent. This can be mitigated by defaulting to disallowing timeout overrides.
> I'm happy to put a patch together and document it at http://incubator.apache.org/jena/documentation/serving_data/.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

[jira] [Commented] (JENA-218) Fuseki should allow timeouts to be specified on a per-request basis

Posted by "Andy Seaborne (Commented) (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/JENA-218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13238408#comment-13238408 ] 

Andy Seaborne commented on JENA-218:
------------------------------------

I've applied the patch but have some comments.

1/ Specifying timeouts: there two timeouts, time to first answer and time to last answer.  Setting the overall timeout high but short time to first answer makes sense as a timeout after first answer before the last is likely to result in bad syntax in the results.

For compatibility with HTTP, the HTTP timeout is going to have to be one number.  This should be time to first answer (and last) because it should correspond to HTTP 408.  We now have the typical problem of HTTP response codes - they go out before the results start.

But for ?timeout= and for the config file, I suggest allowing the ""X,Y" form as well as plain number.  i.e. allowTimeoutOverride is a string (as well as a number).

c.f. QueryExecutionBase.setAnyTimeouts.

2/ Should the presence of fuseki:maximumTimeoutOverride 10 imply fuseki:allowTimeoutOverride=true?

3/ Units.  Elsewhere, including setting the setting timeouts by context, is by milliseconds.  Granted, it might be better to use seconds uniformly but given where we are, maybe milliseconds everywhere is better than a mixture.

     ja:context [ ja:cxtName "arq:queryTimeout" ;  ja:cxtValue "10000" ] ;

I'm open to changing arq:queryTimeout to be seconds.

                
> Fuseki should allow timeouts to be specified on a per-request basis
> -------------------------------------------------------------------
>
>                 Key: JENA-218
>                 URL: https://issues.apache.org/jira/browse/JENA-218
>             Project: Apache Jena
>          Issue Type: Improvement
>          Components: Fuseki
>    Affects Versions: Fuseki 0.2.1
>            Reporter: Alexander Dutton
>            Assignee: Andy Seaborne
>              Labels: needsdocumentation, timeout
>         Attachments: config-tdb.ttl, jena-218-1.diff
>
>
> A query endpoint might want to have different timeouts depending on whether queries are from untrusted or trusted users, or maintenance processes. The timeout could be passed with an X- header, a Timeout header as per http://tools.ietf.org/html/draft-loreto-http-timeout-00, or a query parameter, respecting the system default if none is provided. The query parameter might be less favourable as it'd be harder to filter out for Fuseki instances behind Apache.
> There is a risk that changing the behaviour to allow timeouts to be overridden will lead to DoSs of query endpoints open to the world to some extent. This can be mitigated by defaulting to disallowing timeout overrides.
> I'm happy to put a patch together and document it at http://incubator.apache.org/jena/documentation/serving_data/.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Commented] (JENA-218) Fuseki should allow timeouts to be specified on a per-request basis

Posted by "Paolo Castagna (Commented) (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/JENA-218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13228389#comment-13228389 ] 

Paolo Castagna commented on JENA-218:
-------------------------------------

Alexander, thanks for the patch (I've not looked at it yet). It will not make it the first Fuseki release, since vote process for that has already started.
                
> Fuseki should allow timeouts to be specified on a per-request basis
> -------------------------------------------------------------------
>
>                 Key: JENA-218
>                 URL: https://issues.apache.org/jira/browse/JENA-218
>             Project: Apache Jena
>          Issue Type: Improvement
>          Components: Fuseki
>    Affects Versions: Fuseki 0.2.1
>            Reporter: Alexander Dutton
>              Labels: needsdocumentation, timeout
>         Attachments: config-tdb.ttl, jena-218-1.diff
>
>
> A query endpoint might want to have different timeouts depending on whether queries are from untrusted or trusted users, or maintenance processes. The timeout could be passed with an X- header, a Timeout header as per http://tools.ietf.org/html/draft-loreto-http-timeout-00, or a query parameter, respecting the system default if none is provided. The query parameter might be less favourable as it'd be harder to filter out for Fuseki instances behind Apache.
> There is a risk that changing the behaviour to allow timeouts to be overridden will lead to DoSs of query endpoints open to the world to some extent. This can be mitigated by defaulting to disallowing timeout overrides.
> I'm happy to put a patch together and document it at http://incubator.apache.org/jena/documentation/serving_data/.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Updated] (JENA-218) Fuseki should allow timeouts to be specified on a per-request basis

Posted by "Alexander Dutton (Updated) (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/JENA-218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexander Dutton updated JENA-218:
----------------------------------

    Description: 
A query endpoint might want to have different timeouts depending on whether queries are from untrusted or trusted users, or maintenance processes. The timeout could be passed with an X- header, a Timeout header as per http://tools.ietf.org/html/draft-loreto-http-timeout-00, or a query parameter, respecting the system default if none is provided. The query parameter might be less favourable as it'd be harder to filter out for Fuseki instances behind Apache.

There is a risk that changing the behaviour to allow timeouts to be overridden will lead to DoSs of query endpoints open to the world to some extent. This can be mitigated by defaulting to disallowing timeout overrides.

I'm happy to put a patch together and document it at http://incubator.apache.org/jena/documentation/serving_data/.

  was:
A query endpoint might want to have different timeouts depending on whether queries are from untrusted or trusted users, or maintenance processes. The timeout could be passed with an X- header, a Timeout header as per http://tools.ietf.org/html/draft-loreto-http-timeout-00, or a query parameter, respecting the system default if none is provided. The query parameter might be less favourable as it'd be harder to filter out for Fuseki instances behind Apache.

There is a risk that changing the behaviour to allow timeouts to be overridden will lead to DoSs of query endpoints open to the world to some extent. This can be mitigated by defaulting to disallowing timeout overrides.

I'm happy to put a patchdocu together and document it at http://incubator.apache.org/jena/documentation/serving_data/.

    
> Fuseki should allow timeouts to be specified on a per-request basis
> -------------------------------------------------------------------
>
>                 Key: JENA-218
>                 URL: https://issues.apache.org/jira/browse/JENA-218
>             Project: Apache Jena
>          Issue Type: Improvement
>          Components: Fuseki
>    Affects Versions: Fuseki 0.2.1
>            Reporter: Alexander Dutton
>              Labels: needsdocumentation, timeout
>
> A query endpoint might want to have different timeouts depending on whether queries are from untrusted or trusted users, or maintenance processes. The timeout could be passed with an X- header, a Timeout header as per http://tools.ietf.org/html/draft-loreto-http-timeout-00, or a query parameter, respecting the system default if none is provided. The query parameter might be less favourable as it'd be harder to filter out for Fuseki instances behind Apache.
> There is a risk that changing the behaviour to allow timeouts to be overridden will lead to DoSs of query endpoints open to the world to some extent. This can be mitigated by defaulting to disallowing timeout overrides.
> I'm happy to put a patch together and document it at http://incubator.apache.org/jena/documentation/serving_data/.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Updated] (JENA-218) Fuseki should allow timeouts to be specified on a per-request basis

Posted by "Alexander Dutton (Updated) (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/JENA-218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexander Dutton updated JENA-218:
----------------------------------

    Attachment: jena-218-1.diff

Replacing previous diff with one that doesn't include local changes to .project and .classpath files.
                
> Fuseki should allow timeouts to be specified on a per-request basis
> -------------------------------------------------------------------
>
>                 Key: JENA-218
>                 URL: https://issues.apache.org/jira/browse/JENA-218
>             Project: Apache Jena
>          Issue Type: Improvement
>          Components: Fuseki
>    Affects Versions: Fuseki 0.2.1
>            Reporter: Alexander Dutton
>              Labels: needsdocumentation, timeout
>         Attachments: config-tdb.ttl, jena-218-1.diff
>
>
> A query endpoint might want to have different timeouts depending on whether queries are from untrusted or trusted users, or maintenance processes. The timeout could be passed with an X- header, a Timeout header as per http://tools.ietf.org/html/draft-loreto-http-timeout-00, or a query parameter, respecting the system default if none is provided. The query parameter might be less favourable as it'd be harder to filter out for Fuseki instances behind Apache.
> There is a risk that changing the behaviour to allow timeouts to be overridden will lead to DoSs of query endpoints open to the world to some extent. This can be mitigated by defaulting to disallowing timeout overrides.
> I'm happy to put a patch together and document it at http://incubator.apache.org/jena/documentation/serving_data/.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira