Frank Meier wrote:
thanks for your replies, I tried the use of bucketbrigades as Chris
Kukuchka suggested. Unfortunately this lead to the same behaviour.
I also tried the *hack* approach (accessing the socket directly), where
I had the problem of getting to the socket itself. I didn't understand
how I could use ap_filter_t->ctx since I don't know what is stored
For the top level network filter 'ctx' is a core_net_rec (httpd.h) object.
My version of httpd.h has this definition.
typedef struct core_net_rec {
/** Connection to the client */
apr_socket_t *client_socket;
/** connection record */
conn_rec *c;
core_output_filter_ctx_t *out_ctx;
core_ctx_t *in_ctx;
} core_net_rec;
there, but I used "ap_get_module_config" which should also get me to the
socket. right?
struct apr_socket_t *client_socket =
ap_get_module_config(r->connection->conn_config, &core_module);
Ok, this looks like a far saner way to get to the client socket than the
hack I suggested.
int rv = read(client_socket->socketdes, dummyBuf, len);
but rv is always 0 (if len is 0) / -1 (if len > 0) and errno is 2 (No
such file or directory)
Very interesting, don't have a clue why you are seeing this though. I
don't think read() is even supposed to return ENOENT.
http://docs.sun.com/app/docs/doc/816-0212/6m6nd4nd4?a=view is a manpage
for read() on solaris 9. No ENOENT here. What does your manpage say ?
I think my next step is to implement a test module myself to verify this
strange behaviour and also test it on another OS (linux) since Solaris
sometimes does strange things.
That would be the way to go.
srp
--
http://saju.net.in
