[ 
https://issues.apache.org/jira/browse/JCR-4355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16575325#comment-16575325
 ] 

Alexander Klimetschek commented on JCR-4355:
--------------------------------------------

Thanks for the feedback!

Here is an updated patch:  [^JCR-4355-v2.patch] 

 * Changed "text-based" to "character-based"
 * The current javadoc has a lot of duplication too :) I changed the part to 
"\{@link BinaryDownloadOptions} includes, but is not limited to:" and added a 
note on Content-Disposition type: "Content-Disposition type: whether to show 
the content inline of a page (inline) or enforce a download/save as 
(attachment)". Also linked to the different {{with*()}} methods. Wanted to 
highlight the important settings that a caller needs to be aware of and which 
JCR properties would usually be the source. For the details, one can follow the 
links to BinaryDownloadOptions javadoc then.
 * Added to security considerations of getURI: "If the client is a browser, 
consider use of Content-Disposition type = attachment for executable media 
types such as HTML or Javascript if the content cannot be trusted."

> Javadoc fixes and improvements for new direct binary access API
> ---------------------------------------------------------------
>
>                 Key: JCR-4355
>                 URL: https://issues.apache.org/jira/browse/JCR-4355
>             Project: Jackrabbit Content Repository
>          Issue Type: Improvement
>          Components: jackrabbit-api
>            Reporter: Alexander Klimetschek
>            Priority: Major
>         Attachments: JCR-4355-v2.patch, JCR-4355.diff
>
>
> Here are some changes to the javadocs for the new API: 
> [OAK-7569-api-javadoc-improvements.patch|https://issues.apache.org/jira/secure/attachment/12934364/12934364_OAK-7569-api-javadoc-improvements.patch]
> * more concise descriptions
> * correcting some inaccuracies (clients cannot choose whether to do single or 
> multipart upload, multipart might be strictly required depending on the size)
> * most importantly the upload algorithm (standard partSize calculation was 
> wrong)
> * focus on API users, separated notes to implementors
> * for BinaryDownloadOptions added note from which jcr properties a client 
> would normally take these values from
> * added security considerations



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to