[
https://issues.apache.org/jira/browse/TIKA-1196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13825357#comment-13825357
]
Sergey Beryozkin commented on TIKA-1196:
----------------------------------------
IMHO what needs to be decided upon is: what is more important for Tika Server,
for it supporting all the possible host variations out of the box or expect the
users do more work when the server is accessed remotely. If the security is not
an issue for the Server then it does not make sense to keep the local host by
default a lot, but if it is then opening it up completely by default does not
seem right - it would seem reasonable to me for users actually do more work in
such cases, with the host calculation requiring the least if effort :-), and
with setting up the server certificates taking the most of effort
> JAX-RS server only responds to queries to/from http://localhost
> ---------------------------------------------------------------
>
> Key: TIKA-1196
> URL: https://issues.apache.org/jira/browse/TIKA-1196
> Project: Tika
> Issue Type: Bug
> Components: server
> Affects Versions: 1.4
> Environment: Mac OS X, Windows Server 2008
> Reporter: Rian Stockbower
> Priority: Minor
> Labels: JAXRS, hostname, web-service
> Attachments: tika-1196.patch, tika-1196b.patch, tika-1196c.patch
>
>
> I'm not sure if this is a problem with the Tika JAX-RS server, or with how it
> uses CXF under the hood. Anyway:
> I have a large text extraction job (10-15 million documents) that I'm using
> the web service for. It would be nice to be able to distribute this
> horizontally across multiple nodes to speed up the processing. I had thought
> to have a job queue with a couple consumers, farming out PUT requests across
> several Tika web service endpoints.
> But the JAX-RS web service will only respond to queries made to
> {{http://localhost:9998/tika}}.
> I can't call {{http://hostname:9998/tika}} -- even if it's still a local
> operation.
> Here is a list of things I've tried:
> * I changed line 89 of TikaServerCLI.java to compute the name of the host at
> runtime. No go: the server starts up, and immediately terminates.
> * I changed line 89 of TikaServerCLI.java to be a hostname (not a FQDN), and
> re-compiled:
> ** {{mvn compile -rf :tika-server}} compiles successfully. Start up the
> server, and it terminates, just like when I tried to compute the hostname at
> runtime
> ** {{mvn install}} from the topmost Tika directory gets the service
> responding to both {{http://hostname:9998/tika}} and
> {{http://hostname.domain.net:9998/tika}} (Seemed weird, this is why I was
> thinking it was further up the chain in CXF?)
> In a perfect world:
> # The server should respond to any valid calls that make sense:
> #* 127.0.0.1
> #* localhost
> #* hostname
> #* host.domain.tld
> #* ip_address
> # A {{hostname}} invocation parameter could be used to limit what the service
> responds to when it's started up. (A very optional, nice-to-have.)
--
This message was sent by Atlassian JIRA
(v6.1#6144)
