[jira] [Commented] (QPID-7408) REST API streams compressed message content without a Content-Encoding header
[
https://issues.apache.org/jira/browse/QPID-7408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15958679#comment-15958679
]
ASF subversion and git services commented on QPID-7408:
---
Commit 1790370 from oru...@apache.org in branch 'java/branches/6.0.x'
[ https://svn.apache.org/r1790370 ]
QPID-7408,QPID-7711: Fix various issues with message content REST API
* Set correct Content-Encoding in REST responses for message content
* Avoid double compression when content is compressed and gzip compression is
supported by the client
* Decompress compressed message content if compression is unsupported on client
The following commits have been merged with a lot of manual conflict
resolutions (leaving only 6.0.x relative changes)
svn merge -c 1758395 ^/qpid/java/trunk
svn merge -c 1759379 ^/qpid/java/trunk
svn merge -c 1759829 ^/qpid/java/trunk
svn merge -c 1761399 ^/qpid/java/trunk
svn merge -c 1761561 ^/qpid/java/trunk
svn merge -c 1761567 ^/qpid/java/trunk
> REST API streams compressed message content without a Content-Encoding header
> -
>
> Key: QPID-7408
> URL: https://issues.apache.org/jira/browse/QPID-7408
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: 0.30, 0.32, qpid-java-6.0, qpid-java-6.1
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Minor
> Fix For: qpid-java-6.1
>
> Attachments:
> 0001-QPID-7408-Extend-gunzip-output-stream-from-InflaterO.patch,
> new-compression-tests.diff
>
>
> The Broker for Java supports compressed messages. If I view a compressed
> message through the management console, the Broker sends the content to the
> client without a {{Content-Encoding}} header, so the client treats the bytes
> as if they were uncompressed. If the message's mime type is {{text/*}}, I
> see seeming garbage instead of the inlined text content. If the message's
> mime type is something else the browser handles the content as if it were
> uncompressed. This could confused applications associated with the Browser.
> This could potentially hinder an operator.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7408) REST API streams compressed message content without a Content-Encoding header
[
https://issues.apache.org/jira/browse/QPID-7408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15506412#comment-15506412
]
Keith Wall commented on QPID-7408:
--
The following commit message seems to have not been added automatically by SVN:
QPID-7408: Replace GZIPOutputStreamAdapter with GunzipOutputStream
extending InflaterOutputStream
git-svn-id: https://svn.apache.org/repos/asf/qpid/java/trunk@1761561
13f79535-47bb-0310-9956-ffa450edef68
Alex and I worked on this change together.
> REST API streams compressed message content without a Content-Encoding header
> -
>
> Key: QPID-7408
> URL: https://issues.apache.org/jira/browse/QPID-7408
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: 0.30, 0.32, qpid-java-6.0, qpid-java-6.1
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Minor
> Fix For: qpid-java-6.1
>
> Attachments:
> 0001-QPID-7408-Extend-gunzip-output-stream-from-InflaterO.patch,
> new-compression-tests.diff
>
>
> The Broker for Java supports compressed messages. If I view a compressed
> message through the management console, the Broker sends the content to the
> client without a {{Content-Encoding}} header, so the client treats the bytes
> as if they were uncompressed. If the message's mime type is {{text/*}}, I
> see seeming garbage instead of the inlined text content. If the message's
> mime type is something else the browser handles the content as if it were
> uncompressed. This could confused applications associated with the Browser.
> This could potentially hinder an operator.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7408) REST API streams compressed message content without a Content-Encoding header
[
https://issues.apache.org/jira/browse/QPID-7408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15506409#comment-15506409
]
ASF subversion and git services commented on QPID-7408:
---
Commit 1761567 from [~k-wall] in branch 'java/trunk'
[ https://svn.apache.org/r1761567 ]
QPID-7408: Minor tidy-ups to implementation of GunzipOutputStream
> REST API streams compressed message content without a Content-Encoding header
> -
>
> Key: QPID-7408
> URL: https://issues.apache.org/jira/browse/QPID-7408
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: 0.30, 0.32, qpid-java-6.0, qpid-java-6.1
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Minor
> Fix For: qpid-java-6.1
>
> Attachments:
> 0001-QPID-7408-Extend-gunzip-output-stream-from-InflaterO.patch,
> new-compression-tests.diff
>
>
> The Broker for Java supports compressed messages. If I view a compressed
> message through the management console, the Broker sends the content to the
> client without a {{Content-Encoding}} header, so the client treats the bytes
> as if they were uncompressed. If the message's mime type is {{text/*}}, I
> see seeming garbage instead of the inlined text content. If the message's
> mime type is something else the browser handles the content as if it were
> uncompressed. This could confused applications associated with the Browser.
> This could potentially hinder an operator.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7408) REST API streams compressed message content without a Content-Encoding header
[
https://issues.apache.org/jira/browse/QPID-7408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15503136#comment-15503136
]
Keith Wall commented on QPID-7408:
--
As discussed, I see now this is trickier than it appeared to me. The fact that
the API of {{GzipInputStream#read}} has no way to tell you that it hasn't
received sufficient bytes yet to produce uncompressed output means that
implementing a GunzipOutputStream in terms of GzipInputStream is not possible.
Your implementation relies on your *special*
org.apache.qpid.server.management.plugin.GZIPOutputStreamAdapter.BufferInputStream#read(byte[],
int, int) to return -1 when there are *currently* no more bytes and the fact
that java.util.zip.InflaterInputStream#fill() encountering a -1 happens to
leave the java.util.zip.InflaterInputStream in a valid state for further
reading. I don't think these are good foundations.
I think we have no choice but implement a GunzipOutputStream in terms of
Inflater. As you suggest, we can use Apache Commons Compression as a guide.
> REST API streams compressed message content without a Content-Encoding header
> -
>
> Key: QPID-7408
> URL: https://issues.apache.org/jira/browse/QPID-7408
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: 0.30, 0.32, qpid-java-6.0, qpid-java-6.1
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Minor
> Fix For: qpid-java-6.1
>
> Attachments: new-compression-tests.diff
>
>
> The Broker for Java supports compressed messages. If I view a compressed
> message through the management console, the Broker sends the content to the
> client without a {{Content-Encoding}} header, so the client treats the bytes
> as if they were uncompressed. If the message's mime type is {{text/*}}, I
> see seeming garbage instead of the inlined text content. If the message's
> mime type is something else the browser handles the content as if it were
> uncompressed. This could confused applications associated with the Browser.
> This could potentially hinder an operator.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7408) REST API streams compressed message content without a Content-Encoding header
[
https://issues.apache.org/jira/browse/QPID-7408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15502721#comment-15502721
]
ASF subversion and git services commented on QPID-7408:
---
Commit 1761399 from oru...@apache.org in branch 'java/trunk'
[ https://svn.apache.org/r1761399 ]
QPID-7408: Address review comments
> REST API streams compressed message content without a Content-Encoding header
> -
>
> Key: QPID-7408
> URL: https://issues.apache.org/jira/browse/QPID-7408
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: 0.30, 0.32, qpid-java-6.0, qpid-java-6.1
>Reporter: Keith Wall
>Assignee: Lorenz Quack
>Priority: Minor
> Fix For: qpid-java-6.1
>
> Attachments: new-compression-tests.diff
>
>
> The Broker for Java supports compressed messages. If I view a compressed
> message through the management console, the Broker sends the content to the
> client without a {{Content-Encoding}} header, so the client treats the bytes
> as if they were uncompressed. If the message's mime type is {{text/*}}, I
> see seeming garbage instead of the inlined text content. If the message's
> mime type is something else the browser handles the content as if it were
> uncompressed. This could confused applications associated with the Browser.
> This could potentially hinder an operator.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7408) REST API streams compressed message content without a Content-Encoding header
[
https://issues.apache.org/jira/browse/QPID-7408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15487422#comment-15487422
]
Keith Wall commented on QPID-7408:
--
{{StreamingContent}} troubles me. I don't think we want this on the API.
Couldn't we write a {{GunzipOutputStream}} adapter which would take care of
decompressing the compressed bytes? We'd use this like so:
AbstractQueue.MessageContent#write(new
GunzipOutputStream(httpResponseOutputStream)). Internally, GunzipOutputStream
would need to use a GzipInputStream and employ some buffer shuffling.
GunzipOutputStream could understand the limit too so it would know to stop once
it had produced {{limit}} uncompressed bytes.
> REST API streams compressed message content without a Content-Encoding header
> -
>
> Key: QPID-7408
> URL: https://issues.apache.org/jira/browse/QPID-7408
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: 0.30, 0.32, qpid-java-6.0, qpid-java-6.1
>Reporter: Keith Wall
>Assignee: Lorenz Quack
>Priority: Minor
> Fix For: qpid-java-6.1
>
> Attachments: new-compression-tests.diff
>
>
> The Broker for Java supports compressed messages. If I view a compressed
> message through the management console, the Broker sends the content to the
> client without a {{Content-Encoding}} header, so the client treats the bytes
> as if they were uncompressed. If the message's mime type is {{text/*}}, I
> see seeming garbage instead of the inlined text content. If the message's
> mime type is something else the browser handles the content as if it were
> uncompressed. This could confused applications associated with the Browser.
> This could potentially hinder an operator.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7408) REST API streams compressed message content without a Content-Encoding header
[
https://issues.apache.org/jira/browse/QPID-7408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15473975#comment-15473975
]
ASF subversion and git services commented on QPID-7408:
---
Commit 1759829 from oru...@apache.org in branch 'java/trunk'
[ https://svn.apache.org/r1759829 ]
QPID-7408: [Java Broker, WMC] Fix limiting of compressed content
> REST API streams compressed message content without a Content-Encoding header
> -
>
> Key: QPID-7408
> URL: https://issues.apache.org/jira/browse/QPID-7408
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: 0.30, 0.32, qpid-java-6.0, qpid-java-6.1
>Reporter: Keith Wall
>Assignee: Alex Rudyy
>Priority: Minor
> Fix For: qpid-java-6.1
>
> Attachments: new-compression-tests.diff
>
>
> The Broker for Java supports compressed messages. If I view a compressed
> message through the management console, the Broker sends the content to the
> client without a {{Content-Encoding}} header, so the client treats the bytes
> as if they were uncompressed. If the message's mime type is {{text/*}}, I
> see seeming garbage instead of the inlined text content. If the message's
> mime type is something else the browser handles the content as if it were
> uncompressed. This could confused applications associated with the Browser.
> This could potentially hinder an operator.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7408) REST API streams compressed message content without a Content-Encoding header
[
https://issues.apache.org/jira/browse/QPID-7408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15466792#comment-15466792
]
ASF subversion and git services commented on QPID-7408:
---
Commit 1759379 from oru...@apache.org in branch 'java/trunk'
[ https://svn.apache.org/r1759379 ]
QPID-7408: [Java Broker] Prevent double compression and decompress compressed
message content if compression is unsupported on REST client
> REST API streams compressed message content without a Content-Encoding header
> -
>
> Key: QPID-7408
> URL: https://issues.apache.org/jira/browse/QPID-7408
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: 0.30, 0.32, qpid-java-6.0, qpid-java-6.1
>Reporter: Keith Wall
>Assignee: Alex Rudyy
>Priority: Minor
> Fix For: qpid-java-6.1
>
> Attachments: new-compression-tests.diff
>
>
> The Broker for Java supports compressed messages. If I view a compressed
> message through the management console, the Broker sends the content to the
> client without a {{Content-Encoding}} header, so the client treats the bytes
> as if they were uncompressed. If the message's mime type is {{text/*}}, I
> see seeming garbage instead of the inlined text content. If the message's
> mime type is something else the browser handles the content as if it were
> uncompressed. This could confused applications associated with the Browser.
> This could potentially hinder an operator.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7408) REST API streams compressed message content without a Content-Encoding header
[
https://issues.apache.org/jira/browse/QPID-7408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15451898#comment-15451898
]
Keith Wall commented on QPID-7408:
--
The agreed approach is that the defect that caused the a compressed message
content to be compressed a second time will be fixed. Also the HTTP layer will
be changed so that if a message content is compress, but the client cannot
accept the compressed content, then the HTTP layer should decompress the
content on its behalf. A system test should also be added,
> REST API streams compressed message content without a Content-Encoding header
> -
>
> Key: QPID-7408
> URL: https://issues.apache.org/jira/browse/QPID-7408
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: 0.30, 0.32, qpid-java-6.0, qpid-java-6.1
>Reporter: Keith Wall
>Assignee: Lorenz Quack
>Priority: Minor
> Fix For: qpid-java-6.1
>
>
> The Broker for Java supports compressed messages. If I view a compressed
> message through the management console, the Broker sends the content to the
> client without a {{Content-Encoding}} header, so the client treats the bytes
> as if they were uncompressed. If the message's mime type is {{text/*}}, I
> see seeming garbage instead of the inlined text content. If the message's
> mime type is something else the browser handles the content as if it were
> uncompressed. This could confused applications associated with the Browser.
> This could potentially hinder an operator.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7408) REST API streams compressed message content without a Content-Encoding header
[
https://issues.apache.org/jira/browse/QPID-7408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15451480#comment-15451480
]
Keith Wall commented on QPID-7408:
--
I realise that there is a second related defect. If
{{org.apache.qpid.server.management.plugin.HttpManagementConfiguration#isCompressResponses}}
is set true, currently the {{HttpManagementUtil#getOutputStream()}} will
attempt to recompress the compressed message content again.
> REST API streams compressed message content without a Content-Encoding header
> -
>
> Key: QPID-7408
> URL: https://issues.apache.org/jira/browse/QPID-7408
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: 0.30, 0.32, qpid-java-6.0, qpid-java-6.1
>Reporter: Keith Wall
>Assignee: Lorenz Quack
>Priority: Minor
> Fix For: qpid-java-6.1
>
>
> The Broker for Java supports compressed messages. If I view a compressed
> message through the management console, the Broker sends the content to the
> client without a {{Content-Encoding}} header, so the client treats the bytes
> as if they were uncompressed. If the message's mime type is {{text/*}}, I
> see seeming garbage instead of the inlined text content. If the message's
> mime type is something else the browser handles the content as if it were
> uncompressed. This could confused applications associated with the Browser.
> This could potentially hinder an operator.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7408) REST API streams compressed message content without a Content-Encoding header
[
https://issues.apache.org/jira/browse/QPID-7408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15449138#comment-15449138
]
ASF subversion and git services commented on QPID-7408:
---
Commit 1758395 from [~k-wall] in branch 'java/trunk'
[ https://svn.apache.org/r1758395 ]
QPID-7408: [Java Broker] Stream compressed message content with a
Content-Encoding HTTP header
> REST API streams compressed message content without a Content-Encoding header
> -
>
> Key: QPID-7408
> URL: https://issues.apache.org/jira/browse/QPID-7408
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: 0.30, 0.32, qpid-java-6.0, qpid-java-6.1
>Reporter: Keith Wall
>
> The Broker for Java supports compressed messages. If I view a compressed
> message through the management console, the Broker sends the content to the
> client without a {{Content-Encoding}} header, so the client treats the bytes
> as if they were uncompressed. If the message's mime type is {{text/*}}, I
> see seeming garbage instead of the inlined text content. If the message's
> mime type is something else the browser handles the content as if it were
> uncompressed. This could confused applications associated with the Browser.
> This could potentially hinder an operator.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
