Yes thanks for clearing some tings out.
Of course I never wanted it to be an alternative to the servlet-spec,
however the way I tend to build stuff get's so modular so it's almost
implementing the spec once again :) Bind different requesthandlers to
different uri's is scary close to the httpservlet binding. But it's probably
only because it's actually a a smart way of looking up executable code.
First I started off bulding a server with my own proprietary protocol which
worked just fine. After a while building clients for different languages I
came to the conclusion that it would be smarter to use the http protocol
instead to ease the spread and implementations, understanding, testing etc
of the abstractcache project.
I have solved the parsing of both GET and POST requests now but as I stated
before I find the implementation of the solution to be in the wrong place.
Let's say I wanna contribute to the project by adding some parsing. Where
would you start ?
Something like this perhaps:
1. Create a ParsedHttpRequest which extends HttpRequest and some
implementations of it for POST and GET.
2. Creating a new RequestFactory which purpose is to produce a
ParsedHttpRequest
Yes that's sound cleanest right ?
I hope you forgive my naming suggestions since if it is something I'm bad at
so is it naming conventions :)
If it's clean enough don't you think it could be supplied in a "contrib"
package or something ?
BYTW I created my own HttpServerConnection since I found it a little strange
to set both sendBufferSize and receiveBufferSize to the same sizes.
I came to think of this since I wanted to set the socket options right after
the socket was accepted way before http comes into play and found that the
socket options was overridden. After some grepping I found this bastard :)
Think of it... Let's say an implementor already set his fantastic combo of
socket options then it should'nt be set again right?
I attach my version of the HttpServerConnection so you just can look at it
if you'd like.
Anyway I'm not here for complaining I really really love your work! Hope you
don't take my pointers as dark criticism. I just wanna contribute since I
have been a leech for too long, time to become a seeder instead...
Kindly
//Marcus
Kindly
//Marcus
No I just wanted something which took care of the http protocol and in my
opinion parameters are included into
On 7/27/07, Roland Weber <[EMAIL PROTECTED]> wrote:
>
> Hello Marcus,
>
> > I have created a http server package for my project abstractcache.sf.net(not
> > released yet). I have used the httpcore components to build a BIO server
> > which performs really well.
>
> It's great that you found the package useful.
> Thanks for letting us know.
>
> > Since I'm quite familiar with the servlet spec I assumed that
> > HttpRequest.getParams actually would return the parsed query string in
> the
> > GET case and the parsed body in the POST case.
>
> HttpCore is in no way an alternative to the Servlet API.
> We're not building a web container or any such thing.
> We're building a core library for HTTP communication.
> The closest thing to a server-side handler we have is
> class HttpService in the protocol package, and the
> package description mentions that we don't recommend
> it as an alternative to the Servlet API:
>
> http://jakarta.apache.org/httpcomponents/httpcomponents-core/httpcore/apidocs/org/apache/http/protocol/package-summary.html
>
> All get/setParams refer to parameters for our framework,
> as provided by implementations of interface HttpParams:
>
> http://jakarta.apache.org/httpcomponents/httpcomponents-core/httpcore/apidocs/org/apache/http/params/HttpParams.html
>
> > I have gone through your xref and javadocs for 2 hours now and cannot
> find
> > any parsing facilities which does parameter parsing. Headers are parsed
> I
> > see.
>
> We need to parse headers in order to execute HTTP. There
> is no reason for us to parse a query string, let alone a
> message entity. It is not relevant for executing HTTP.
> We only need the scheme and target host of a URI. In the
> old HttpClient 3.x code, there is a class URI that you
> could use for the query string. But you might as well
> use java.net.URI.
>
> > Both of these are quite easy to parse but I thought that it was done
> already
> > since the package otherwise is in such a complete state. But you perhaps
> > want to leave parameter parsing to the implementor of the core package.
>
> Parameter parsing is an application level problem. It is not
> in the scope of HttpComponents, certainly not of core. At the
> moment, we're not dealing with content anywhere, we just pass
> it through. There might be a case for convenience entities
> somewhere in HttpClient 4.0, but even those wouldn't be concerned
> with query strings. We will discuss whether to port the multipart
> request entity from 3.1 to 4.0 later this year. That's outgoing
> though (client), not incoming (server).
>
> If you want a request representation with parameters, you will
> have to define your own interfaces and implementations. You can
> extend the HttpRequest of course. But parsing and storing the
> parameters from the query string or message body will remain
> the task of your application. HttpCore scope ends when the
> message is delivered to your application.
>
> hope that helps,
> Roland
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
>
>
package net.sf.abstractcache.server.http;
import org.apache.http.impl.SocketHttpClientConnection;
import org.apache.http.impl.AbstractHttpClientConnection;
import org.apache.http.impl.AbstractHttpServerConnection;
import org.apache.http.impl.io.SocketHttpDataReceiver;
import org.apache.http.impl.io.SocketHttpDataTransmitter;
import org.apache.http.params.HttpParams;
import org.apache.http.params.HttpConnectionParams;
import org.apache.http.HttpInetConnection;
import org.apache.http.io.HttpDataReceiver;
import org.apache.http.io.HttpDataTransmitter;
import java.net.Socket;
import java.net.InetAddress;
import java.net.SocketException;
import java.io.IOException;
/**
* User: mahe
* Date: 2007-jul-27
* Time: 13:24:04
*/
public class SocketHttpServerConnectionImpl extends AbstractHttpServerConnection implements HttpInetConnection
{
private volatile boolean open;
private Socket socket = null;
public SocketHttpServerConnectionImpl()
{
super();
}
protected void assertNotOpen()
{
if (this.open) {
throw new IllegalStateException("Connection is already open");
}
}
protected void assertOpen() {
if (!this.open) {
throw new IllegalStateException("Connection is not open");
}
}
protected HttpDataReceiver createHttpDataReceiver(
final Socket socket,
int buffersize,
final HttpParams params) throws IOException
{
return new SocketHttpDataReceiver(socket, buffersize, params);
}
protected HttpDataTransmitter createHttpDataTransmitter(
final Socket socket,
int buffersize,
final HttpParams params) throws IOException
{
return new SocketHttpDataTransmitter(socket, buffersize, params);
}
public void bind(
final Socket socket,
final HttpParams params) throws IOException
{
assertNotOpen();
if (socket == null)
{
throw new IllegalArgumentException("Socket may not be null");
}
if (params == null) {
throw new IllegalArgumentException("HTTP parameters may not be null");
}
boolean isHandled = params.getBooleanParameter("http.socket.isHandled", false);
if(!isHandled)
socket.setTcpNoDelay(HttpConnectionParams.getTcpNoDelay(params));
if(!isHandled)
socket.setSoTimeout(HttpConnectionParams.getSoTimeout(params));
//if(socket.getSoLinger())
if(!isHandled)
{
int linger = HttpConnectionParams.getLinger(params);
if (linger >= 0)
{
socket.setSoLinger(linger > 0, linger);
}
}
this.socket = socket;
int receiveBufferSize = socket.getReceiveBufferSize();
int sendBufferSize = socket.getSendBufferSize();
if(!isHandled)
{
receiveBufferSize = params.getIntParameter("http.socket.receive-buffer-size", HttpConnectionParams.getSocketBufferSize(params));
sendBufferSize = params.getIntParameter("http.socket.send-buffer-size", HttpConnectionParams.getSocketBufferSize(params));
}
init(
createHttpDataReceiver(socket, receiveBufferSize, params),
createHttpDataTransmitter(socket, sendBufferSize, params),
params);
this.open = true;
}
public boolean isOpen() {
return this.open;
}
protected Socket getSocket() {
return this.socket;
}
public InetAddress getLocalAddress() {
if (this.socket != null) {
return this.socket.getLocalAddress();
} else {
return null;
}
}
public int getLocalPort() {
if (this.socket != null) {
return this.socket.getLocalPort();
} else {
return -1;
}
}
public InetAddress getRemoteAddress() {
if (this.socket != null) {
return this.socket.getInetAddress();
} else {
return null;
}
}
public int getRemotePort() {
if (this.socket != null) {
return this.socket.getPort();
} else {
return -1;
}
}
public void setSocketTimeout(int timeout) {
assertOpen();
if (this.socket != null) {
try {
this.socket.setSoTimeout(timeout);
} catch (SocketException ignore) {
// It is not quite clear from the Sun's documentation if there are any
// other legitimate cases for a socket exception to be thrown when setting
// SO_TIMEOUT besides the socket being already closed
}
}
}
public int getSocketTimeout()
{
if (this.socket != null) {
try {
return this.socket.getSoTimeout();
} catch (SocketException ignore) {
return -1;
}
} else {
return -1;
}
}
public void shutdown() throws IOException
{
this.open = false;
Socket tmpsocket = this.socket;
if (tmpsocket != null) {
tmpsocket.close();
}
}
public void close() throws IOException
{
if (!this.open)
{
return;
}
this.open = false;
doFlush();
try
{
try
{
this.socket.shutdownOutput();
}
catch (IOException ignore)
{
}
try
{
this.socket.shutdownInput();
}
catch (IOException ignore)
{
}
}
catch (UnsupportedOperationException ignore)
{
// if one isn't supported, the other one isn't either
}
this.socket.close();
}
}---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
