You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tika.apache.org by "Sergey Beryozkin (JIRA)" <ji...@apache.org> on 2013/11/18 15:43:24 UTC

[jira] [Comment Edited] (TIKA-1196) JAX-RS server only responds to queries to/from http://localhost

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

Sergey Beryozkin edited comment on TIKA-1196 at 11/18/13 2:43 PM:
------------------------------------------------------------------

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 having to do more work in such cases, with the host calculation requiring the least of effort :-), and with setting up the server certificates taking the most of effort


was (Author: sergey_beryozkin):
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)