Hi,

I've started a simple fanr repo over http on a server with:

fan fanr::WebRepoMain /path/to/fileRepo -port 8084

and patched it through a reverse proxy on apache.

When I try to publish pods with

fanr publish -r http://fanr.wotever.co.uk/ myutils

the upload works and I can see the pod in a query, such as:

http://fanr.wotever.co.uk/query?my*

but the publish command always fails with:

Publish myUtils-1.0.0 [y/n]: y
ERROR: publish command failed
fanr::RemoteErr: Cannot parse response as JSON [100]
  fanr::WebRepo.parseRes (WebRepo.fan:208)
  fanr::WebRepo.publish (WebRepo.fan:107)
  fanr::PublishCmd.publish (PublishCmd.fan:72)
  fanr::PublishCmd.run (PublishCmd.fan:43)
  fanr::Main.main (Main.fan:52)
  java.lang.reflect.Method.invoke (Method.java:597)
  fan.sys.Method.invoke (Method.java:559)
  fan.sys.Method$MethodFunc.callOn (Method.java:230)
  fan.sys.Method.callOn (Method.java:139)
  fanx.tools.Fan.callMain (Fan.java:175)
  fanx.tools.Fan.executeType (Fan.java:140)
  fanx.tools.Fan.execute (Fan.java:41)
  fanx.tools.Fan.run (Fan.java:298)
  fanx.tools.Fan.main (Fan.java:336)
Cause:
  sys::IOErr: No input stream for response 100
  web::WebClient.resIn (WebClient.fan:140)
  fanr::WebRepo.parseRes (WebRepo.fan:206)
  fanr::WebRepo.publish (WebRepo.fan:107)
  fanr::PublishCmd.publish (PublishCmd.fan:72)
  fanr::PublishCmd.run (PublishCmd.fan:43)
  fanr::Main.main (Main.fan:52)
  java.lang.reflect.Method.invoke (Method.java:597)
  fan.sys.Method.invoke (Method.java:559)
  fan.sys.Method$MethodFunc.callOn (Method.java:230)
  fan.sys.Method.callOn (Method.java:139)
  fanx.tools.Fan.callMain (Fan.java:175)
  fanx.tools.Fan.executeType (Fan.java:140)
  fanx.tools.Fan.execute (Fan.java:41)
  fanx.tools.Fan.run (Fan.java:298)
  fanx.tools.Fan.main (Fan.java:336)

Any thoughts on what I'm doing wrong?

The code must not be handling 100 continue. Sort of odd that your proxy server would be doing that since WebRepoMain doesn't use that sort of POST request processing. But that is the problem - your proxy server is changing the request flow to require 100 continue

Yeah, you're right. It looks like Apache's mod_proxy_http is doing the dirty for when I run fanr directly (say, on port 80) it all works fine.

My apache vhost conf is as simple as:

<VirtualHost *:80>
 ServerName fanr.wotever.co.uk
 ProxyPass / http://127.0.0.1:8884/
 ProxyPassReverse / http://127.0.0.1:8884/
</VirtualHost>

But looking around it seems mod_proxy asynchronously sends the 100 Continue before replying with the actual request from the server.

• Making mod_proxy_http send back response asynchronously (w/o 100 Continue)
• HTTP proxy - expect 100 and authentication
• Apache and mod_proxy not handling HTTP 100-continue from client HTTP 417

Some cite it's a problem with an Expect early request header, but there seems to be no resolute solution.

Further digging reveals that Apache's mod_proxy_http is (somewhat) correct as the 100 Continue response is part of the HTTP/1.1 spec.

A quick fix is for Fanr to use HTTP/1.0 as that doesn't specify any 1xx response codes, hence none will be sent.

Is this worthy of a ticket?

Yes I will look at it. At the beach this week, but its already on my todo list. Right now WebClient doesn't automatically handle 100, and often times you need low level control of checking for that before posting the content. But there are some convenience methods on WebClient which I should change to just automatically handle 100 like I do redirects.

Going back and looking at the code, I actually think the Fantom side is all correct. That code is requesting a 100 continue from the server, then does the post, then reads the server's response after post is done. That response after the POST should be 200, but your proxy server is still returning 100. That doesn't make sense - the 100 should only be returned before the POST. So that looks something fishy on proxy server side of things.

I've looked into that too but there does not seem to be any workaround for apache. They seem to not think that is a bug and won't fix it. I guess it's a different interpretation of the spec. I guess I feel apache is wrong on that one though.

It works with nginx, so one solution is to either use nginx or use it as a proxy in front of apache and have it serve fanr requests.

On the other apache is (still) so prevalent as the font-end web server in front of java/fantom servers I'm not sure it's such a good idea to be incompatible with it, it's not like there is such a huge gain/need to use 100-continue.

Some kind of APACHE_MODE then? Something that will tell server to act differently when it works with Apache?