[jira] [Updated] (JENA-1813) Join optimization transform results in incorrect query results

[Shawn Smith (Jira)]

 [ 
https://issues.apache.org/jira/browse/JENA-1813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Shawn Smith updated JENA-1813:
--
Description: 
I think I've found a query where TransformJoinStrategy incorrectly decides that 
a query is linear such that a "join" operation can be replaced by a "sequence" 
operation.  As a result, the query returns incorrect results.  Disabling 
optimizations with "qe.getContext().set(ARQ.optimization, false)" fixes the 
issue.

Here's the query: 
{noformat}
PREFIX  :  
SELECT ?a
WHERE {
  GRAPH :graph { :s :p ?a }
  GRAPH :graph {
SELECT (?b AS ?a)
WHERE { :t :q ?b }
GROUP BY ?b
  }
}
{noformat}
Here's the data to test it with (two quads, as Trig): 
{noformat}
@prefix :   .
:graph {
:s  :p  "a" .
:t  :q  "b" .
}
{noformat}
I expected the query to return zero results because the two GRAPH clauses can't 
find compatible bindings for ?a.  But, in practice, Jena returns ?a="a" and 
logs a warning:
{noformat}
[main] WARN  BindingUtils - merge: Mismatch : "a" != "b"{noformat}
Note the warning is actually coming from QueryIterProjectMerge.java, not 
BindingUtils.java.  With more complicated queries and datasets, this issue can 
result in thousands or millions of logged warnings.

The query plan before optimization looks like this:
{noformat}
(project (?a)
  (join
(graph 
  (bgp (triple   ?a)))
(graph 
  (project (?a)
(extend ((?a ?b))
  (group (?b)
(bgp (triple   
?b
{noformat}
Optimization replaces "join" with "sequence" which fails to detect conflicts on 
?a:
{noformat}
(project (?a)
  (sequence
(graph 
  (bgp (triple   ?a)))
(graph 
  (project (?a)
(extend ((?a ?/b))
  (group (?/b)
(bgp (triple   
?/b
{noformat}
For convenience, here's Java code that reproduces the bug:
{noformat}
import org.apache.jena.query.ARQ;
import org.apache.jena.query.Dataset;
import org.apache.jena.query.DatasetFactory;
import org.apache.jena.query.QueryExecution;
import org.apache.jena.query.QueryExecutionFactory;
import org.apache.jena.query.ResultSet;
import org.apache.jena.riot.Lang;
import org.apache.jena.riot.RDFParser;
import org.junit.Test;

public class QueryTest {

@Test
public void testGraphQuery() {
String query = "" +
"PREFIX  :  \n" +
"SELECT ?a\n" +
"WHERE {\n" +
"  GRAPH :graph { :s :p ?a }\n" +
"  GRAPH :graph {\n" +
"SELECT (?b AS ?a)\n" +
"WHERE { :t :q ?b }\n" +
"GROUP BY ?b\n" +
"  }\n" +
"}\n";
String data = "" +
"@prefix :   .\n" +
":graph {\n" +
"  :s  :p  \"a\" .\n" +
"  :t  :q  \"b\" .\n" +
"}\n";

Dataset ds = DatasetFactory.create();
RDFParser.fromString(data).lang(Lang.TRIG).parse(ds);

try (QueryExecution qe = QueryExecutionFactory.create(query, ds)) {
qe.getContext().set(ARQ.optimization, true);  // flipping this to 
false fixes the test
ResultSet rs = qe.execSelect();
if (rs.hasNext()) {
System.out.println(rs.nextBinding());
throw new AssertionError("Result set should be empty");
}
}
}
}
{noformat}

  was:
I think I've found a query where TransformJoinStrategy incorrectly decides that 
a query is linear such that a "join" operation can be replaced by a "sequence" 
operation.  As a result, the query returns incorrect results.  Disabling 
optimizations with "qe.getContext().set(ARQ.optimization, false)" fixes the 
issue.

Here's the query: 
{noformat}
PREFIX  :  
SELECT ?a
WHERE {
  GRAPH :graph { :s :p ?a }
  GRAPH :graph {
SELECT (?b AS ?a)
WHERE { :t :q ?b }
GROUP BY ?b
  }
}
{noformat}
Here's the data to test it with (two quads, as Trig): 
{noformat}
@prefix :   .
:graph {
:s  :p  "a" .
:t  :q  "b" .
}
{noformat}
 I expected the query to return zero results because the two GRAPH clauses 
can't find compatible bindings for ?a.  But, in practice, Jena returns ?a="a" 
and logs a warning:
{noformat}
[main] WARN  BindingUtils - merge: Mismatch : "a" != "b"{noformat}
Note the warning is actually coming from QueryIterProjectMerge.java, not 
BindingUtils.java.  With more complicated queries and datasets, this issue can 
result in thousands or millions 

[jira] [Updated] (JENA-1813) Join optimization transform results in incorrect query results

[Shawn Smith (Jira)]

 [ 
https://issues.apache.org/jira/browse/JENA-1813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Shawn Smith updated JENA-1813:
--
Description: 
I think I've found a query where TransformJoinStrategy incorrectly decides that 
a query is linear such that a "join" operation can be replaced by a "sequence" 
operation.  As a result, the query returns incorrect results.  Disabling 
optimizations with "qe.getContext().set(ARQ.optimization, false)" fixes the 
issue.

Here's the query: 
{noformat}
PREFIX  :  
SELECT ?a
WHERE {
  GRAPH :graph { :s :p ?a }
  GRAPH :graph {
SELECT (?b AS ?a)
WHERE { :t :q ?b }
GROUP BY ?b
  }
}
{noformat}
Here's the data to test it with (two quads, as Trig): 
{noformat}
@prefix :   .
:graph {
:s  :p  "a" .
:t  :q  "b" .
}
{noformat}
 I expected the query to return zero results because the two GRAPH clauses 
can't find compatible bindings for ?a.  But, in practice, Jena returns ?a="a" 
and logs a warning:
{noformat}
[main] WARN  BindingUtils - merge: Mismatch : "a" != "b"{noformat}
Note the warning is actually coming from QueryIterProjectMerge.java, not 
BindingUtils.java.  With more complicated queries and datasets, this issue can 
result in thousands or millions of logged warnings.

The query plan before optimization looks like this:
{noformat}
(project (?a)
  (join
(graph 
  (bgp (triple   ?a)))
(graph 
  (project (?a)
(extend ((?a ?b))
  (group (?b)
(bgp (triple   
?b
{noformat}
Optimization replaces "join" with "sequence" which fails to detect conflicts on 
?a:
{noformat}
(project (?a)
  (sequence
(graph 
  (bgp (triple   ?a)))
(graph 
  (project (?a)
(extend ((?a ?/b))
  (group (?/b)
(bgp (triple   
?/b
{noformat}
For convenience, here's Java code that reproduces the bug:
{noformat}
import org.apache.jena.query.ARQ;
import org.apache.jena.query.Dataset;
import org.apache.jena.query.DatasetFactory;
import org.apache.jena.query.QueryExecution;
import org.apache.jena.query.QueryExecutionFactory;
import org.apache.jena.query.ResultSet;
import org.apache.jena.riot.Lang;
import org.apache.jena.riot.RDFParser;
import org.junit.Test;

public class QueryTest {

@Test
public void testGraphQuery() {
String query = "" +
"PREFIX  :  \n" +
"SELECT ?a\n" +
"WHERE {\n" +
"  GRAPH :graph { :s :p ?a }\n" +
"  GRAPH :graph {\n" +
"SELECT (?b AS ?a)\n" +
"WHERE { :t :q ?b }\n" +
"GROUP BY ?b\n" +
"  }\n" +
"}\n";
String data = "" +
"@prefix :   .\n" +
":graph {\n" +
"  :s  :p  \"a\" .\n" +
"  :t  :q  \"b\" .\n" +
"}\n";

Dataset ds = DatasetFactory.create();
RDFParser.fromString(data).lang(Lang.TRIG).parse(ds);

try (QueryExecution qe = QueryExecutionFactory.create(query, ds)) {
qe.getContext().set(ARQ.optimization, true);  // flipping this to 
false fixes the test
ResultSet rs = qe.execSelect();
if (rs.hasNext()) {
System.out.println(rs.nextBinding());
throw new AssertionError("Result set should be empty");
}
}
}
}
{noformat}

  was:
I think I've found a query where TransformJoinStrategy incorrectly decides that 
a query is linear such that a "join" operation can be replaced by a "sequence" 
operation.  As a result, the query returns incorrect results.  Disabling 
optimizations with "qe.getContext().set(ARQ.optimization, false)" fixes the 
issue.

Here's the query: 
{noformat}
PREFIX  :  
SELECT ?a
WHERE {
  GRAPH :graph { :s :p ?a }
  GRAPH :graph {
SELECT (?b AS ?a)
WHERE { :t :q ?b }
GROUP BY ?b
  }
}
{noformat}
Here's the data to test it with (two triples, as Trig): 
{noformat}
@prefix :   .
:graph {
:s  :p  "a" .
:t  :q  "b" .
}
{noformat}
 I expected the query to return zero results because the two GRAPH clauses 
can't find compatible bindings for ?a.  But, in practice, Jena returns ?a="a" 
and logs a warning:
{noformat}
[main] WARN  BindingUtils - merge: Mismatch : "a" != "b"{noformat}
Note the warning is actually coming from QueryIterProjectMerge.java, not 
BindingUtils.java.  With more complicated queries and datasets, this issue can 
result in thousands or 

[jira] [Created] (JENA-1813) Join optimization transform results in incorrect query results

[Shawn Smith (Jira)]

Shawn Smith created JENA-1813:
-

 Summary: Join optimization transform results in incorrect query 
results
 Key: JENA-1813
 URL: https://issues.apache.org/jira/browse/JENA-1813
 Project: Apache Jena
  Issue Type: Bug
  Components: ARQ
Affects Versions: Jena 3.13.1
Reporter: Shawn Smith


I think I've found a query where TransformJoinStrategy incorrectly decides that 
a query is linear such that a "join" operation can be replaced by a "sequence" 
operation.  As a result, the query returns incorrect results.  Disabling 
optimizations with "qe.getContext().set(ARQ.optimization, false)" fixes the 
issue.

Here's the query: 
{noformat}
PREFIX  :  
SELECT ?a
WHERE {
  GRAPH :graph { :s :p ?a }
  GRAPH :graph {
SELECT (?b AS ?a)
WHERE { :t :q ?b }
GROUP BY ?b
  }
}
{noformat}
Here's the data to test it with (two triples, as Trig): 
{noformat}
@prefix :   .
:graph {
:s  :p  "a" .
:t  :q  "b" .
}
{noformat}
 I expected the query to return zero results because the two GRAPH clauses 
can't find compatible bindings for ?a.  But, in practice, Jena returns ?a="a" 
and logs a warning:
{noformat}
[main] WARN  BindingUtils - merge: Mismatch : "a" != "b"{noformat}
Note the warning is actually coming from QueryIterProjectMerge.java, not 
BindingUtils.java.  With more complicated queries and datasets, this issue can 
result in thousands or millions of logged warnings.

The query plan before optimization looks like this:
{noformat}
(project (?a)
  (join
(graph 
  (bgp (triple   ?a)))
(graph 
  (project (?a)
(extend ((?a ?b))
  (group (?b)
(bgp (triple   
?b
{noformat}
Optimization replaces "join" with "sequence" which fails to detect conflicts on 
?a:
{noformat}
(project (?a)
  (sequence
(graph 
  (bgp (triple   ?a)))
(graph 
  (project (?a)
(extend ((?a ?/b))
  (group (?/b)
(bgp (triple   
?/b
{noformat}
For convenience, here's Java code that reproduces the bug:
{noformat}
import org.apache.jena.query.ARQ;
import org.apache.jena.query.Dataset;
import org.apache.jena.query.DatasetFactory;
import org.apache.jena.query.QueryExecution;
import org.apache.jena.query.QueryExecutionFactory;
import org.apache.jena.query.ResultSet;
import org.apache.jena.riot.Lang;
import org.apache.jena.riot.RDFParser;
import org.junit.Test;

public class QueryTest {

@Test
public void testGraphQuery() {
String query = "" +
"PREFIX  :  \n" +
"SELECT ?a\n" +
"WHERE {\n" +
"  GRAPH :graph { :s :p ?a }\n" +
"  GRAPH :graph {\n" +
"SELECT (?b AS ?a)\n" +
"WHERE { :t :q ?b }\n" +
"GROUP BY ?b\n" +
"  }\n" +
"}\n";
String data = "" +
"@prefix :   .\n" +
":graph {\n" +
"  :s  :p  \"a\" .\n" +
"  :t  :q  \"b\" .\n" +
"}\n";

Dataset ds = DatasetFactory.create();
RDFParser.fromString(data).lang(Lang.TRIG).parse(ds);

try (QueryExecution qe = QueryExecutionFactory.create(query, ds)) {
qe.getContext().set(ARQ.optimization, true);  // flipping this to 
false fixes the test
ResultSet rs = qe.execSelect();
if (rs.hasNext()) {
System.out.println(rs.nextBinding());
throw new AssertionError("Result set should be empty");
}
}
}
}
{noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [DRAFT] Apache Jena - January 2020

[ajs6f]

+1.

Thanks Andy!

ajs6f

> On Jan 8, 2020, at 10:12 AM, Andy Seaborne  wrote:
> 
> ## Description:
> The mission of Jena is the creation and maintenance of software related to 
> Java framework for building Semantic Web applications
> 
> ## Issues:
> There are no issues requiring board attention.
> 
> ## Membership Data:
> 
> Apache Jena was founded 2012-04-18 (8 years ago)
> There are currently 18 committers and 14 PMC members in this project.
> The Committer-to-PMC ratio is 9:7.
> 
> Community changes, past quarter:
> - No new PMC members. Last addition was Aaron Coburn on 2019-01-22.
> - No new committers. Last addition was Greg Albiston on 2019-07-08.
> 
> ## Project Activity:
> 
> Jena 3.13.1 was released on 2019-10-11.
> 
> The project operates aspires to a releases every 3-4 months and is now
> discussing the 3.14.0 this month, subject to PMC availability.
> 
> The 3.14.0 has several contributions from new people, outside the main
> committers.
> 
> The project is also discussing reorganising its mailing lists to reduce the 
> volume on dev@ by moving github traffic to a separate list. The hope is that 
> with less low-level emails and pull request specific emails, it will 
> encourage discussion on the longer term direction of Jena.
> 
> ## Community Health:
> 
> Activity on the users@ and dev@ lists is about normal. The new people
> contributing pull request is encouraging and hopefully some these people will 
> remain going forward.
> 
> We expect a drop in dev@ email when the github traffic is directed to another 
> list.
> 
> email:
> dev@jena.apache.org same level: (566 compared to 562)
> us...@jena.apache.org same label (291 emails compared to 292)
> 
> JIRA:
> 44 issues opened in JIRA, past quarter (12% increase)
> 39 issues closed in JIRA, past quarter (18% increase)
> 
> Github:
> 49 PRs opened on GitHub, past quarter (36% increase) 46 PRs closed

[DRAFT] Apache Jena - January 2020

[Andy Seaborne]

## Description:
The mission of Jena is the creation and maintenance of software related 
to Java framework for building Semantic Web applications


## Issues:
There are no issues requiring board attention.

## Membership Data:

Apache Jena was founded 2012-04-18 (8 years ago)
There are currently 18 committers and 14 PMC members in this project.
The Committer-to-PMC ratio is 9:7.

Community changes, past quarter:
- No new PMC members. Last addition was Aaron Coburn on 2019-01-22.
- No new committers. Last addition was Greg Albiston on 2019-07-08.

## Project Activity:

Jena 3.13.1 was released on 2019-10-11.

The project operates aspires to a releases every 3-4 months and is now
discussing the 3.14.0 this month, subject to PMC availability.

The 3.14.0 has several contributions from new people, outside the main
committers.

The project is also discussing reorganising its mailing lists to reduce 
the volume on dev@ by moving github traffic to a separate list. The hope 
is that with less low-level emails and pull request specific emails, it 
will encourage discussion on the longer term direction of Jena.


## Community Health:

Activity on the users@ and dev@ lists is about normal. The new people
contributing pull request is encouraging and hopefully some these people 
will remain going forward.


We expect a drop in dev@ email when the github traffic is directed to 
another list.


email:
dev@jena.apache.org same level: (566 compared to 562)
us...@jena.apache.org same label (291 emails compared to 292)

JIRA:
44 issues opened in JIRA, past quarter (12% increase)
39 issues closed in JIRA, past quarter (18% increase)

Github:
49 PRs opened on GitHub, past quarter (36% increase) 46 PRs closed

[jira] [Commented] (JENA-1812) Migrate blank node hash algorithm from MD5 to SHA-256

[Andy Seaborne (Jira)]

[ 
https://issues.apache.org/jira/browse/JENA-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17010684#comment-17010684
 ] 

Andy Seaborne commented on JENA-1812:
-

Changing to another hash is a good idea.

The length of the hash is visible in N-Triples output (32 hex chars). 

I think keeping to a 128 bit length is better unless there is a need to change 
to a longer one.

Jena does not need cryptographic secure hashes for the blank node id 
allocation. It is a way to generate unique ids for the {{_:a}} and {{[]}} forms 
at scale (i.e. avoiding needing to keep a temporary map of label to 
parser-unique allocated label). Each parser run seeds the hash with a 122 bit 
random number.

A possible hash is murmur3_128, which is available in the Google Guava and in 
shaded form, Jena already has it as a dependency.

murmur3_128 is fast, not secure.

There may be other suitable hashes.

(There is another place MD5 is used in TDB1 and TDB2 but there it gets onto 
disk. It does not need to be secure in that usage either.)

> Migrate blank node hash algorithm from MD5 to SHA-256
> -
>
> Key: JENA-1812
> URL: https://issues.apache.org/jira/browse/JENA-1812
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: ARQ
>Reporter: Nicolas Seydoux
>Assignee: Andy Seaborne
>Priority: Trivial
>  Labels: easyfix
> Fix For: Jena 3.14.0
>
>   Original Estimate: 5m
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> MD5 is a deprecated hashing algorithm, and even though it is not used on 
> sensitive data in the context of Jena, its usage is picked up by security 
> softwares as a security flaw. This may reduce the incentive to use Jena in 
> commercial products, and computing SHA-256 hashes is not prohibitively more 
> expensive than MD5.
>  
> Therefore, I suggest to migrate from using MD5 hashes to SHA-256.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Assigned] (JENA-1812) Migrate blank node hash algorithm from MD5 to SHA-256

[Andy Seaborne (Jira)]

 [ 
https://issues.apache.org/jira/browse/JENA-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Seaborne reassigned JENA-1812:
---

Assignee: Andy Seaborne

> Migrate blank node hash algorithm from MD5 to SHA-256
> -
>
> Key: JENA-1812
> URL: https://issues.apache.org/jira/browse/JENA-1812
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: ARQ
>Reporter: Nicolas Seydoux
>Assignee: Andy Seaborne
>Priority: Trivial
>  Labels: easyfix
> Fix For: Jena 3.14.0
>
>   Original Estimate: 5m
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> MD5 is a deprecated hashing algorithm, and even though it is not used on 
> sensitive data in the context of Jena, its usage is picked up by security 
> softwares as a security flaw. This may reduce the incentive to use Jena in 
> commercial products, and computing SHA-256 hashes is not prohibitively more 
> expensive than MD5.
>  
> Therefore, I suggest to migrate from using MD5 hashes to SHA-256.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (JENA-1811) Fuseki: Unexpected query string params interfere with content-type dispatch.

[Andy Seaborne (Jira)]

 [ 
https://issues.apache.org/jira/browse/JENA-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Seaborne resolved JENA-1811.
-
Resolution: Fixed

> Fuseki: Unexpected query string params interfere with content-type dispatch.
> 
>
> Key: JENA-1811
> URL: https://issues.apache.org/jira/browse/JENA-1811
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Fuseki
>Affects Versions: Jena 3.13.1
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Major
> Fix For: Jena 3.14.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> The code checks for unexpected params before looking at the content type.
> The comment is correct:
> {noformat}
>  * Query parameters (URL query string or HTML form)
>  * Content-Type header
>  * Otherwise it is a plain REST (quads) operation.chooseOperation
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (JENA-1811) Fuseki: Unexpected query string params interfere with content-type dispatch.

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/JENA-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17010550#comment-17010550
 ] 

ASF subversion and git services commented on JENA-1811:
---

Commit c1cbd7cc54a11c1cd8d8cf5af9465acdd146ff4c in jena's branch 
refs/heads/master from Andy Seaborne
[ https://gitbox.apache.org/repos/asf?p=jena.git;h=c1cbd7c ]

Merge pull request #666 from afs/http-rdf

JENA-1811: Dispatch on Content-Type. Accumulated code and comment cleanup.

> Fuseki: Unexpected query string params interfere with content-type dispatch.
> 
>
> Key: JENA-1811
> URL: https://issues.apache.org/jira/browse/JENA-1811
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Fuseki
>Affects Versions: Jena 3.13.1
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Major
> Fix For: Jena 3.14.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> The code checks for unexpected params before looking at the content type.
> The comment is correct:
> {noformat}
>  * Query parameters (URL query string or HTML form)
>  * Content-Type header
>  * Otherwise it is a plain REST (quads) operation.chooseOperation
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (JENA-1811) Fuseki: Unexpected query string params interfere with content-type dispatch.

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/JENA-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17010549#comment-17010549
 ] 

ASF subversion and git services commented on JENA-1811:
---

Commit 4fc653268460823afc0c347a8745c496976fe48b in jena's branch 
refs/heads/master from Andy Seaborne
[ https://gitbox.apache.org/repos/asf?p=jena.git;h=4fc6532 ]

JENA-1811: Dispatch on Content-Type before query string checking


> Fuseki: Unexpected query string params interfere with content-type dispatch.
> 
>
> Key: JENA-1811
> URL: https://issues.apache.org/jira/browse/JENA-1811
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Fuseki
>Affects Versions: Jena 3.13.1
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Major
> Fix For: Jena 3.14.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> The code checks for unexpected params before looking at the content type.
> The comment is correct:
> {noformat}
>  * Query parameters (URL query string or HTML form)
>  * Content-Type header
>  * Otherwise it is a plain REST (quads) operation.chooseOperation
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [jena] afs merged pull request #666: JENA-1811: Dispatch on Content-Type. Accumulated code and comment cleanup.

[GitBox]

afs merged pull request #666: JENA-1811: Dispatch on Content-Type. Accumulated 
code and comment cleanup.
URL: https://github.com/apache/jena/pull/666
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [jena] afs merged pull request #665: Update year in NOTICE

[GitBox]

afs merged pull request #665: Update year in NOTICE
URL: https://github.com/apache/jena/pull/665
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Updated] (JENA-1811) Fuseki: Unexpected query string params interfere with content-type dispatch.

[Andy Seaborne (Jira)]

 [ 
https://issues.apache.org/jira/browse/JENA-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Seaborne updated JENA-1811:

Summary: Fuseki: Unexpected query string params interfere with content-type 
dispatch.  (was: Fuseki: Unexpected query string params interfer with 
content-type dispatch.)

> Fuseki: Unexpected query string params interfere with content-type dispatch.
> 
>
> Key: JENA-1811
> URL: https://issues.apache.org/jira/browse/JENA-1811
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Fuseki
>Affects Versions: Jena 3.13.1
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Major
> Fix For: Jena 3.14.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> The code checks for unexpected params before looking at the content type.
> The comment is correct:
> {noformat}
>  * Query parameters (URL query string or HTML form)
>  * Content-Type header
>  * Otherwise it is a plain REST (quads) operation.chooseOperation
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [jena] afs commented on a change in pull request #666: JENA-1811: Dispatch on Content-Type. Accumulated code and comment cleanup.

[GitBox]

afs commented on a change in pull request #666: JENA-1811: Dispatch on 
Content-Type. Accumulated code and comment cleanup.
URL: https://github.com/apache/jena/pull/666#discussion_r364147314
 
 

 ##
 File path: 
jena-fuseki2/jena-fuseki-core/src/main/java/org/apache/jena/fuseki/auth/Auth.java
 ##
 @@ -103,4 +104,20 @@ public static boolean allow(String user, AuthPolicy 
policy, Runnable notAllowed)
 notAllowed.run();
 return false;
 }
+
+/**
+ * Calculate the value of the "Authentication" HTTP header for basic auth. 
Basic
+ * auth is not secure when used over HTTP (the password can be extracted). 
Use
+ * with HTTPS is better.
+ * 
+ * Unlike digest auth, basic auth can be setup without an extra round trip 
to the
+ * server, making it easier for scripts where teh body is not replayable.
 
 Review comment:
   Thanks for raising this. I can't find a definitive answer by searching the 
web.
   
   Not sure about the ``. It is legal HTML (not xHTML). I don't get a 
warning/error in Eclipse. The POM has `none` and given the 
scale and age of Jena, other places will have no closing ``.
   
   Elsewhere, I have projects using Java11 and no special configuration of the 
javadoc plugin.
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [jena] afs commented on a change in pull request #666: JENA-1811: Dispatch on Content-Type. Accumulated code and comment cleanup.

[GitBox]

afs commented on a change in pull request #666: JENA-1811: Dispatch on 
Content-Type. Accumulated code and comment cleanup.
URL: https://github.com/apache/jena/pull/666#discussion_r364143752
 
 

 ##
 File path: 
jena-arq/src/main/java/org/apache/jena/atlas/web/TypedInputStream.java
 ##
 @@ -47,11 +43,11 @@ private TypedInputStream(InputStream in)
 public TypedInputStream(InputStream in, String contentType)
 { this(in, ContentType.create(contentType), null) ; }
 
-public TypedInputStream(InputStream in, String mediaType, String charset)
-{ this(in, mediaType, charset, null) ; }
-
-public TypedInputStream(InputStream in, String mediaType, String charset, 
String baseURI)
-{ this(in, ContentType.create(mediaType, charset), baseURI) ; }
+//public TypedInputStream(InputStream in, String mediaType, String charset)
+//{ this(in, mediaType, charset, null) ; }
+//
+//public TypedInputStream(InputStream in, String mediaType, String 
charset, String baseURI)
+//{ this(in, ContentType.create(mediaType, charset), baseURI) ; }
 
 Review comment:
   Agreed.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [jena] afs commented on a change in pull request #666: JENA-1811: Dispatch on Content-Type. Accumulated code and comment cleanup.

[GitBox]

afs commented on a change in pull request #666: JENA-1811: Dispatch on 
Content-Type. Accumulated code and comment cleanup.
URL: https://github.com/apache/jena/pull/666#discussion_r364143738
 
 

 ##
 File path: 
jena-fuseki2/jena-fuseki-core/src/main/java/org/apache/jena/fuseki/auth/Auth.java
 ##
 @@ -103,4 +104,20 @@ public static boolean allow(String user, AuthPolicy 
policy, Runnable notAllowed)
 notAllowed.run();
 return false;
 }
+
+/**
+ * Calculate the value of the "Authentication" HTTP header for basic auth. 
Basic
+ * auth is not secure when used over HTTP (the password can be extracted). 
Use
+ * with HTTPS is better.
+ * 
+ * Unlike digest auth, basic auth can be setup without an extra round trip 
to the
+ * server, making it easier for scripts where teh body is not replayable.
 
 Review comment:
   Done


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [jena] afs commented on a change in pull request #666: JENA-1811: Dispatch on Content-Type. Accumulated code and comment cleanup.

[GitBox]

afs commented on a change in pull request #666: JENA-1811: Dispatch on 
Content-Type. Accumulated code and comment cleanup.
URL: https://github.com/apache/jena/pull/666#discussion_r364143722
 
 

 ##
 File path: 
jena-rdfconnection/src/main/java/org/apache/jena/rdfconnection/examples/RDFConnectionExample6.java
 ##
 @@ -40,4 +40,3 @@ public static void main(String ...args) {
 }
 }
 }
-
 
 Review comment:
   Git copes either way (I think). These example changes are removing an extra 
blank line. It was "}\n\n".


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services