Hello

[Da...@netscape.net]

Hello. My name is David Bryan. I think I have the right list here. I am in the process of writing (actually have a very simple prototype working) a module in the same sense of the word as mod_echo that is supporting a new protocol (SIP for TCP, since for now there is no UDP support) for Apache. Things are going well, but a ran into a couple of things where I am using cludgey fixes, and was hoping someone could suggest a more elegant approach. I'm posting here rather than the module lists since these questions seem to have more in commom with some of the internal stuff than a normal module. I am presently working with/building against 2.0a4.

1) Right now, when a message comes in, I need to look the first line to determine protocol (i.e., I'm going to ignore it if the first line is HTTP something, or for that matter anything I am not interested in). Since I am reading a line from c->client, I'm reading from a BUFF. Problem is, I don't really want to pull the line, since if I reject it (return DECLINED) I want that first line to still be there for the HTTP stuff. I did this by implementing "ap_blookstring()" in buff.c, which has essentially the same signature as bread(), but doesn't remove the line from the BUFF. Problem of course is that this is a change to Apache, so if I want others to use my module either I need to find a better way to do this that I am just missing, or need to get something like my function integrated into the BUFF library. Any thoughts or ideas?

2) Similarly, I want to parse the message, but eventually feed the whole message to another process (i.e., read it, then read it again). I thought about creating another buffer, and pushing into it as I read the first buffer, than using this new buffer for the second pass read. Problem is that buffers seem to have to have an iol associated with them. This is a similar problem to above, only above I cared only about the first line, so a fix was easy. I guess essentially what I am hoping is there is a way to do a "soft buffer" where you read and write it, but it is not associated with a file or socket. I can always implement that in my module (it would be straight forward to do), but I want to try to stick with Apache standard stuff if I can, and was hoping there was a way to create a BUFF that is written, then read in the same piece of code w/no file/socket associated with it. 

Thanks in advance!

David Bryan

----------
Get your own FREE, personal Netscape Webmail account today at http://home.netscape.com/webmail/

Re: Hello

[Manoj Kasichainula <ma...@io.com>]

Please wrap your messages to have 72-character lines or so. Thanks.

On Wed, Jun 14, 2000 at 07:10:10PM -0400, DavidABryan@netscape.net wrote:
> 1) Right now, when a message comes in, I need to look the first line
> to determine protocol (i.e., I'm going to ignore it if the first
> line is HTTP something, or for that matter anything I am not
> interested in). Since I am reading a line from c->client, I'm
> reading from a BUFF. Problem is, I don't really want to pull the
> line, since if I reject it (return DECLINED) I want that first line
> to still be there for the HTTP stuff. I did this by implementing
> "ap_blookstring()" in buff.c

Not knowing much about SIP:

Is there any useful situation when SIP and HTTP would be run on the
same directories or locations, on the same port? I wouldn't think so.
If I'm correct, then I'd say the best thing to do would be to just not
bother with this case, and just enable the relevant protocol module
appropriately in VirtualHost sections.

> 2) Similarly, I want to parse the message, but eventually feed the
> whole message to another process (i.e., read it, then read it
> again).

Is this a seperate httpd child process? Doesn't sound like it from
what you're saying below.

> hoping there was a way to create a BUFF that is written, then read
> in the same piece of code w/no file/socket associated with it. 

I'd think the right way to do this would be some sort of pipe iol;
either one based on the result of a pipe() or socketpair() system
call, or one that just uses a buffer. Both of these are tricks that
Java use.