Don't know how to turn off directoryindex

[dynamodan]

Sorry if this is out of context here, but I noticed that the running instance is serving up a directoryIndex. How can I turn this off? It is less of a concern if I can count on runner.getContextServer().isPromiscuous() == false (not sure where to set that!). Are these settings accessible from the JavaBridgeRunner instance, or??

Thanks in advance.

[cplerch]

Which instance of JavaBridge are you running: JavaBridgeTemplate.war or Standalone jar? On which servlet container do you run it (if any): Tomcat? Version? Please give us more specific information on your runtime configuration. Regards, Chris 2017-02-24 22:47 GMT+01:00 Dynamo Dan <notifications@github.com>:

…

Sorry if this is out of context here, but I noticed that the running instance is serving up a directoryIndex. How can I turn this off? It is less of a concern if I can count on runner.getContextServer().isPromiscuous() == false (not sure where to set that!). Are these settings accessible from the JavaBridgeRunner instance, or?? Thanks in advance. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#43>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIA12yWmy56ZBJ-p4b8jQKwllLgcf7nwks5rf0_tgaJpZM4MLtpS> .

[dynamodan]

I'm running the standalone version included by a dependency in the pom.xml of my maven project, and then using this statement within my java program:
final io.soluble.pjb.bridge.JavaBridgeRunner runner = io.soluble.pjb.bridge.JavaBridgeRunner.getInstance(javaBridgePort);

So I'm guessing there is some system property I need to set, or maybe some function to call on runner (or perhaps an http object gotten from runner?) . I just don't know what.

[cplerch]

Using the standalone version means that you are using the embedded, proprietary http server, which has this behaviour hard coded: whenever you ask for a file that is in fact a directory it will serve a directory index. Sorry, there is no way in the current version to turn it off by setting some parameter or system property. TBD: future enhancement or wont fix. Seb? 2017-02-28 16:49 GMT+01:00 Dynamo Dan <notifications@github.com>:

…

I'm running the standalone version included by a dependency in the pom.xml of my maven project, and then using this statement within my java program: final io.soluble.pjb.bridge.JavaBridgeRunner runner = io.soluble.pjb.bridge.JavaBridgeRunner.getInstance(javaBridgePort); So I'm guessing there is some system property I need to set, or maybe some function to call on runner (or perhaps an http object gotten from runner?) . I just don't know what. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#43 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIA120xpsvwAZYe576-dKGcQz8BdaxZvks5rhEHygaJpZM4MLtpS> .

[belgattitude]

Sorry took some days off. My long term idea was to remove the support of the internal http server (JavaBridgeRunner)... Mostly because:

1. I haven't used it (I've always deployed on Tomcat)
2. I had the feeling it was made for testing purposes (not made with scaling and performance in mind)
3. I don't really know how to support it.

Of course, this is not a definitive plan... To be sure @dynamodan can you give us more info about the intended use ?

And check if solutions like embedding jetty or undertow (only 1M) in your jar is not a better option (Embedding Tomcat is also possible but more heavy) I guess, those solutions will give you more solid server experience

What do you think ?

[cplerch]

I agree that the internl http server should be phased out. Proposal: - I could do a quick fix for @dynamodan <https://github.com/dynamodan>'s issue by providing 2 new runner methods enableDirectoryIndex() and disableDirectoryIndex() with default = disabled. - At the same time we should deprecate the internal http server by deprecating the JavaBridgeRunner class and announce its removal at the next major release. What do you think? 2017-03-01 11:09 GMT+01:00 Sébastien Vanvelthem <notifications@github.com>:

…

Sorry took some days off. My long term idea was to remove the support of the internal http server (JavaBridgeRunner)... Mostly because: 1. I haven't used it (I've always deployed on Tomcat) 2. I had the feeling it was made for testing purposes (not made with scaling and performance in mind) 3. I don't really know how to support it. Of course, this is not a definitive plan... To be sure @dynamodan <https://github.com/dynamodan> can you give us more info about the intended use ? And check if solutions like embedding jetty <https://www.eclipse.org/jetty/documentation/9.4.x/embedding-jetty.html> or undertow <https://github.com/undertow-io/undertow/tree/master/examples> (only 1M) in your jar is not a better option *(Embedding Tomcat is also possible but more heavy)* I guess, those solutions will give you more solid server experience What do you think ? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#43 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIA12_WYC4W6FW5J7nY6lUkblTbLQH9Jks5rhUPbgaJpZM4MLtpS> .

[dynamodan]

I don't want to run Tomcat. Embedding Jetty seems like a better route. If there's something wrong with using the current standalone server, then fix it, rather than just deprecating JavaBridgeRunner for no specific reason. (Sorry if that sounds rude)

For now, I've determined that creating an empty folder, cd'ing to that folder and then running from there effectively disables the directory listing (by virtue of there being nothing to list). There's probably a way to set the docroot too, not sure how to do that either. Startup variable?

[belgattitude]

Hi @dynamodan.

Don't worry too much about deprecations, there's probably a long road before we remove things, and if we do, we'll increment major version... and keep fixes possibles.

Please keep in mind, that @cplerch and myself have absolutely no idea about usage people might do with the bridge... We just keep focus on what we actually use or imagine with it. So it's very welcome you share your thoughts, otherwise we may never be aware.

That said,

If there's something wrong with using the current standalone server, then fix it, rather than just deprecating JavaBridgeRunner for no specific reason.

I'm not sure if the original phpjavabridge developers made the Runner for prod systems or even imagine customizations... There's a doc: http://php-java-bridge.sourceforge.net/pjb/desktop-apps.php but I'm pretty sure I remember some warnings about production on the mailing list. Remember no jetty or undertow, grizzly at that time.

So, with that in mind... are you going with jetty ? Or do you prefer working with the JavaBridgeRunner (I believe it works) ?

[belgattitude]

@cplerch

Depending on answers from @dynamodan ... I'm totally agree with your propositions:

• 2 new runner methods enableDirectoryIndex() and disableDirectoryIndex() with default = disabled.
• At the same time we should deprecate the internal http server

Could be nice to document how to embed jetty or undertow when deprecating the internal http server. @dynamodan are you open to help on this ?

[dynamodan]

Here's the situation as best I can describe it. We have redundant codebases, one in Java, and one in PHP. Instead of maintaining them both, we are doing bug fixes and new features in the Java codebase, and have the PHP code call the functions in the Java codebase, hence my need for the bridge. Most of it is internal between systems behind firewall, but I still don't like the idea of serving a directory listing.

I would be happy to help with embedding jetty.

Also, depending on how far I get with php-java-bridge, I may even use it to replace my quercus integration which on another project, goes the other direction -- calling php code from java in a templating application for a billing system.

[belgattitude]

I would be happy to help with embedding jetty.

👍, would be great ! I would not include a jetty dependency in the bridge but I see it more like a documentation (for example a markdown doc in the ./doc folder: howto_embed_jetty.md or a better name)... No need to be precise, but at least provide the gradle deps, and the how to register the servlet and it's context. I did something similar here: https://github.com/belgattitude/pjb-starter-springboot/blob/master/src/main/java/io/soluble/pssb/Application.java for spring-boot... I believe you'll end up with something very similar on Jetty. Let me know your thoughts...

replace my quercus integration

Good to know, be sure to read the considerations and some benchmarks. The bridge is very sensitive to roundtrips... (where quercus is a real PHP/JVM implementation). There's some limitations to keep in mind.

[belgattitude]

FYI, I plan to write a doc website about the bridge... But I'm very slow at it, you can have a look to a work in progress on the soluble-japha client site: http://docs.soluble.io/soluble-japha/ (needs fixes)

[dynamodan]

Well I've played around with jetty a bit, and the first problem I'm running into is jetty's inability to deal with the lack of an EOF when running the doPut(). The client never sends an EOF so jetty times out the request after 30 seconds. I'm probably doing something way wrong.

[belgattitude]

Not sure to understand, neither that you did something wrong ;)

I'm not experienced in Java at all but If you suspect something wrong about the client (I guess the PHP one), I can help... Also that you can override the doPut()

@Override
protected void doPut(HttpServletRequest request, HttpServletResponse response)
        throws ServletException, IOException {
    // make some tests here
}

Let me know how it goes...

[dynamodan]

Oh yes, I have the doPut() override function in place.

[dynamodan]

In the try block, it always times out on the handleRequests(is, os) and the stack trace shows the timeout happening in the bridge parser's read function (and subsequently jetty's http read stack).