Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Don't know how to turn off directoryindex #43

Closed
dynamodan opened this issue Feb 24, 2017 · 32 comments
Closed

Don't know how to turn off directoryindex #43

dynamodan opened this issue Feb 24, 2017 · 32 comments
Assignees
@belgattitude @cplerch
Labels
enhancement
Milestone
7.0.0

Comments

@dynamodan
Copy link

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
Copy link
Contributor

cplerch commented Feb 25, 2017 via email

@dynamodan
Copy link
Author

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
Copy link
Contributor

cplerch commented Feb 28, 2017 via email

@belgattitude
Copy link
Owner

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
Copy link
Contributor

cplerch commented Mar 1, 2017 via email

@dynamodan
Copy link
Author

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
Copy link
Owner

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
Copy link
Owner

@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
Copy link
Author

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
Copy link
Owner

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
Copy link
Owner

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
Copy link
Author

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
Copy link
Owner

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
Copy link
Author

Oh yes, I have the doPut() override function in place.
jedit - javabridgeservlet java modified _036

@dynamodan
Copy link
Author

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).
zol ubuntu1604-p6720f -documents-git_bwman-splunktocsv_037

@cplerch
Copy link
Contributor

cplerch commented Mar 2, 2017 via email

@belgattitude
Copy link
Owner

belgattitude commented Mar 2, 2017 •
edited

Looks weird,

@dynamodan can you confirm that the doGet method works ?

PS:
I might be very wrong on that one, but have you registered the 'io.soluble.pjb.servlet.ContextLoaderListener' as well ?

<listener>
     <listener-class>io.soluble.pjb.servlet.ContextLoaderListener</listener-class>
</listener>

Please ignore if totally out of context ;)

@belgattitude
Copy link
Owner

Might be again totally wrong, but on the sourceforge website, the handleRequests() is called directly on RemoteHttpServletContextFactory ctx = new RemoteHttpServletContextFactory(this, getServletContext(), request, request, response) which is a bit different from your use ctx.getBridge().handleRequest()...

See:

RemoteHttpServletContextFactory ctx = new RemoteHttpServletContextFactory(this,
  getServletContext(), request, request, response);

response.setHeader("X_JAVABRIDGE_CONTEXT", ctx.getId());
response.setHeader("Pragma", "no-cache");
response.setHeader("Cache-Control", "no-cache");

try {
  ctx.handleRequests(request.getInputStream(), response.getOutputStream());
} finally {
  ctx.destroy();
}

@dynamodan
Copy link
Author

can you confirm that the doGet method works

Yes, the doGet method works. Also, the doPut method doesn't hang when I send rubbish payloads from other web clients with the PUT method. (Advance REST Client was handy for this.) Of course the java bridge didn't know what to do with test messages being sent as the payload and threw another error, but at least Parser.read() wasn't hanging.

have you registered the 'io.soluble.pjb.servlet.ContextLoaderListener' as well?

It might be out of context, I dunno. I'm not using any xml config like that, i.e. web.xml, *.war files or nothing like that, everything is in source code. How would I register that using java statements?

which is a bit different from your use ctx.getBridge().handleRequest()

Yeah I started from that example. The reason stuff is broken out like that is from me trying to sort out exactly where the code execution was hanging. It was a lot messier before I posted that screenshot. ;)

@dynamodan
Copy link
Author

dynamodan commented Mar 2, 2017 •
edited

UPDATE: embedding Tomcat works just fine, so the problem is somewhere in Jetty. In my maven's pom.xml I added:

		<dependency>
			<groupId>org.apache.tomcat.embed</groupId>
			<artifactId>tomcat-embed-core</artifactId>
			<version>7.0.75</version>
		</dependency>		
		<dependency>
			<groupId>org.apache.tomcat</groupId>
			<artifactId>tomcat-juli</artifactId>
			<version>7.0.75</version>
		</dependency>

And then starting Tomcat with a very, very minimal set of java statements it works fine (well still have to give it some work to do, hah).

public void startTomcat() {
	Tomcat tomcat = new Tomcat();
        tomcat.setPort(8087);
        Context ctx = tomcat.addContext("/", new File(".").getAbsolutePath());
        Tomcat.addServlet(ctx, "jbs", new JavaBridgeServlet());
        ctx.addServletMapping("/*", "jbs");
        try {
			tomcat.start();
			log("started, now waiting for connections...");
			tomcat.getServer().await();
		} catch (Exception e) {
			warning(e.getMessage());
		}
}

@belgattitude
Copy link
Owner

belgattitude commented Mar 2, 2017 •
edited

How would I register that using java statements? (io.soluble.pjb.servlet.ContextLoaderListener)

Not sure how to with Jetty, but I've had to do on it with spring-boot, see here

Eventually look at https://kielczewski.eu/2013/11/using-embedded-jetty-spring-mvc/, there's an example of ContextLoaderListener registration.

Update: as you had success with Tomcat, looks the ContextLoaderListener might not be needed... Are you on Windows/Unix, using the latest soluble-japha client for tests ? (php version ?) Sorry I'm might be out of context here... would love to be a little more experienced on the bridge to help but need to start somewhere ;)

@cplerch
Copy link
Contributor

cplerch commented Mar 3, 2017 via email

@dynamodan
Copy link
Author

I will work out a minimal code base to demonstrate the jetty bug. It might take me a few days.

@cplerch
Copy link
Contributor

cplerch commented Mar 3, 2017 via email

@belgattitude
Copy link
Owner

belgattitude commented Mar 3, 2017 via email

@belgattitude
Copy link
Owner

Hey @chris,

I'll plan to release some upstream fixes soon (7.0.1, see #50 )... Especially the bugfix there:

4fc1b40?diff=split

Could be nice to include the runner.enabeDirectoryIndex() if it's still ok for you to do ?

Simply push on develop and we'll have an option for @dynamodan

All the best

@cplerch
Copy link
Contributor

cplerch commented Mar 6, 2017 via email

@belgattitude
Copy link
Owner

Hi Chris,

My mind was away ;) I'll update the changelog and link the issue. Will be included in 7.0.0.

Thanks a lot.

(Always good to put the issue number in the commit message for reference, like "working on #43")

@belgattitude belgattitude added this to the 7.0.0 milestone Mar 6, 2017
@belgattitude
Copy link
Owner

Hi Chris,

for ensuring no bc-break, or too much divergences from the original project.

Can I revert the default behaviour of "enableDirectoryIndex()" to true ?

belgattitude added a commit that referenced this issue Mar 6, 2017
@belgattitude
Updated changelog with items from #43 and #49
db30668
belgattitude added a commit that referenced this issue Mar 6, 2017
@belgattitude
Updated changelog with items from #43
b49e9dc
@belgattitude
Copy link
Owner

belgattitude commented Mar 6, 2017 •
edited

Hey @dynamodan,

Thanks for code snippets, I've set up a recipe document from your examples (we can improve later).

Please use the issue #51 instead for future comment about embedding as this one will be closed soon

(Currently living in the develop branch, under ./docs/recipes_embedding.md)

belgattitude added a commit that referenced this issue Mar 6, 2017
@belgattitude
Creating doc recipe for embedding #43, #51
0fe1ed4
belgattitude added a commit that referenced this issue Mar 6, 2017
@belgattitude
Creating doc recipe for embedding #43, #51
6ffd522
@cplerch
Copy link
Contributor

cplerch commented Mar 6, 2017 via email

@belgattitude
Copy link
Owner

Looks you always go a step forward ;)

Indeed a 403.. As it look not possible, let's keep it as todo... and hope with the introduction of embedding recipe #51 nobody will use it again.

I'll just put false be default and close. Thanks for your precisions

belgattitude added a commit that referenced this issue Mar 6, 2017
@belgattitude
Directory index is by default to false, #43
8b490e2
@belgattitude belgattitude mentioned this issue Mar 6, 2017
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@belgattitude belgattitude

@cplerch cplerch

Labels
enhancement
Projects
None yet
Milestone
7.0.0
Development

No branches or pull requests
3 participants
@belgattitude @dynamodan @cplerch