Eckhard Lehmann wrote: >>>The only thing to do for configuration is, to extend the text/html mime >>>type (in $APACHE/conf/mime.types) by the .rvt extension: >>> >>>... >>>text/html html htm rvt >>>...
>>I don't think that's quite right... we don't want the Rivet handler to >>parse html files...does it try to? > No, it does not. I have created a translate function, registered with > ap_hook_translate_name(). It checks for the file ending - which is done > by parsing the request_rec::args field. This seems to be the only place > where the file (relative to the server root) is accessible as Hrm... this is quite different from how 1.3 does things. I'm not convinced it's right, but... let's use it for now until we figure out if there is a better way or not. > /file.rvt?param1=value1¶m2=value2 ... > > It sets the request_rec::filename member to the complete file. I let the > handlers (Rivet_SendContent and Rivet_TranslateUri) return DECLINED, if > the extension is not .rvt: > > ... > if (!Rivet_IsRivetFile(r->filename)) > return DECLINED; > ... > I have a problem here: the request_rec, which is given as argument to > the handlers, is not complete - unfortunately. All the file and uri > related members are not set - even worse: they are not even set to NULL > but contain garbage :-/. Ah... you are probably going to need to integrate apreq 2 ( http://httpd.apache.org/apreq/ ) into the apache-2 subdirectory. > This is funny and irritating to me... I think that it must be possible > somehow, to get at a more valuable request_rec during the hook > processing, but I did not find out how... The Apache API is very poorly > documented :-(. > It would be nice if someone who has more experience with the Apache2 API > could try to fix this or point me at a way to get it "right"... Maybe > the module itself is responsible for setting the file and uri members to > the appropriate request_rec? The relevant files, at least in the 1.3 version of Rivet, are these: apache_multipart_buffer.c apache_multipart_buffer.h apache_request.c apache_request.h I just copied them in, instead of requiring people to get and install apreq. I know the API isn't documented that well... there are a couple of other lists that you might want to be on 1) The apreq list. It's low traffic, the guys there are very helpful, and they know the C API well. 2) [email protected] - http://httpd.apache.org/lists.html the main dev list. It's pretty high traffic, but if someone knows the API, it's these guys. That web page also mentions a module writers list, but I don't know if it's active or not. By the way, did you reorganize the code to separate out the 'independant' files and make sure things still compile? Once you do that, I think there are no longer any blocks to putting this in subversion! I guess it's also high time that we figure out how to use subversion branches, so that the current code can become 1_0... -- David N. Welton - http://www.dedasys.com/davidw/ Linux, Open Source Consulting - http://www.dedasys.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
