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

Jason Gerlowski commented on SOLR-17355:
----------------------------------------

As the feature is undocumented, there's a bit of murkiness around our 
backcompat obligations here.  Is it worth retaining through 10.0, or might it 
be safe to remove in (e.g.) 9.7 or 9.8

> Deprecate (or remove) special 'wt=json' support from filestore "get file" API 
> ------------------------------------------------------------------------------
>
>                 Key: SOLR-17355
>                 URL: https://issues.apache.org/jira/browse/SOLR-17355
>             Project: Solr
>          Issue Type: Improvement
>      Security Level: Public(Default Security Level. Issues are Public) 
>          Components: Package Manager, v2 API
>            Reporter: Jason Gerlowski
>            Priority: Minor
>
> Our filestore has a "get file" API, which returns the contents of a filestore 
> entry.
> In almost all cases, this API returns verbatim whatever bytes are associated 
> with the entry in the filestore.  But there's an exception: if "wt=json" is 
> specified, the API will take the bytes stored in the filestore, attempt to 
> string-ify them, and then package those into a JSON response (complete with 
> 'responseHeader', etc.).
>  
> This hidden functionality is undocumented, error-prone (it doesn't support 
> binary content, for instance), makes the response hard to clients to parse, 
> and complicates code on the server side as well.
> We should consider deprecating/removing it if there's no compelling purpose 
> I'm missing.  Or alternatively: document, test, and harden the functionality 
> (e.g. base64 encode binary content).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org

Reply via email to