Tim Allison resolved TIKA-1627.
Resolution: Won't Fix
> Authentication for fileUrl
> Key: TIKA-1627
> URL: https://issues.apache.org/jira/browse/TIKA-1627
> Project: Tika
> Issue Type: Improvement
> Components: server
> Affects Versions: 1.9
> Reporter: Jamshid Afshar
> The fileUrl feature in 1.9-SNAPSHOT is great! Are there plans for letting the
> client provide auth credentials for the request to the remote source
> (fileUrl)? Seems tika would need support for HTTP Basic/Digest
> username:password, then HTTPS certificates, and maybe AWS S3 access+secret
> keys. But, I guess S3 auth can be used now if the client provides a signed
> I tried the (old and deprecated?) HTTP url syntax containing
> username:password, but that is apparently ignored. Tika gets a 401 and that
> causes tika to respond with a 500 error.
> $ curl -H "fileUrl: http://user:passw...@example.com/foo.jpg" -H "Accept:
> application/json" -X PUT http://localhost:9998/meta
> HTTP/1.1 500 Server Error
> I think it's fine to require credentials to be provided in each request, but
> others might want them configurable on the server, probably by domain or
> domain + path.
> A weird alternative solution to this might be for tika to be like a proxy --
> pass through any Authorization: or Cookie: from the request and forward any
> 401/403 response from the remote source (fileUrl) to the tika client. I
> wonder if that might make an OAuth handler for the remote source
> Sorry if this isn't the right place to suggest this.
This message was sent by Atlassian JIRA