Dmitry the Zuryanovich wrote: >On Thu, May 19, 2005 at 11:01:25PM +0200, David N. Welton wrote: > > >>>I think there is no difference beetween GET and HEAD. I just want to get >>>the equal results ;-) I use the "black-box" cybrenetic way. >>> >>> >>There is a definite difference between GET and HEAD. >> >> > >Well, is that's a my /as the developer using mod_rivet/ problem? I just >serve the request. I serve the content. And I *must* get the request inside of >the rivet code I expect it to serve. > >
I think the best "quick fix" is to try taking out that code that I listed below. See if that works. If it does, then we can think about how to make things work in general. >>You mean it doesn't actuall pass those as part of the URL?! Well, with >>mod_rewrite you can still work around that. You can remap something like: >> >> > >Well, this problem is allready solved. I just map the CGI-style stuff >(all that ? and &'s) to the virtual directory. And I map the >Sony-Ericsson's hated = to -'s. > > This is a distinct problem, different from GET vs HEAD, but I'm convinced that to solve it you should use mod_rewrite instead of a 404 handler. >>>>Well, I think if the GET works, why should I care about HEAD? I do not >>>>want to install the mod_rewrite for HEAD. >>>> >>>> >>mod_rewrite ships with Apache, isn't really all that bulky, and does >>exactly what you need. I think it's the best solution. >> >> > > Well, you do not understand me. I think that GET and HEAD is exactly >the same thing handled by apache and calling _my_ script. Including the case of >HEAD the requester gets only the real head of the request (while I HOLD IT!). > If you say "I cant do it now" - well, I'll rewrite it in some >other technology, no problem. May be even with mod_rewrite. > > I think PHP is going to do the same thing Rivet does with HEAD requests - well, it may do some headers, but it won't actually send out a body. Try the quick fix solution and see if that works to solve your immediate problem, then we can go from there to come up with a general solution. >>>You may not trust me, but is DOES only for .mid files, not for .jad/.jars ;-) >>>I'm shocked ;-) >>> >>> >>Weird. I think I'd have to see some dumps and traces to really get an >>idea of what's going on. >> >> > >Well, thay have a right to send HEAD. Why the 610 and 630 does it only >for .mid files - I do not know. > > They can send HEAD all they want, but they shouldn't expect to get anything more than headers back:-) Anything else is really going outside the protocol. We can figure out a way to make it work for you, but it's not going to necessarily be folded back into the Rivet sources... >>>We are playing with the SMPP 3.4 (written on Perl on hacked version of >>>Net::smpp) as the smpp daemons while the site is written on rivet ( >>>undersite, www.undesite.ru, in english ;-) ) >>>Mysql, base64::encode and to the database. It works ;-) >>> >>> >> I saw it ;-) That's cool - but it just a sort of "TCL IS PORTABLE!". >>Does it has some practical usage? >> As for me, I want some other-than-java programming language compiling >>to J2ME devices. >> Java bores me ;-( >> >> It's not quite Tcl, and the point is eventually to be able to write scripts, instead of compiled code, for J2ME devices. >>I might also do some WML for a few sites I run, but I'm still thinking >>about it. I don't get if there's a way to make any money from it since >>you can't really do advertisements or anything like that. >> >> > > The main problem of WML is that you *must* keep your's pages under >1.5kilobyte weight. But - not exactly, in compiled mode! Do you know >that "http://www."; is represented as ONE byte (while wap server compiles >your's WML page to the content it actually sends)? > > Hrm, I think for what I need (nothing fancy), it's all doable. >>Ah, well what I had to say is that I found the code that cuts things off >>when using HEAD: >> >> See if commenting it out fixes things, and let us know. -- David N. Welton - http://www.dedasys.com/davidw/ Apache, Linux, Tcl Consulting - http://www.dedasys.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
