You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Srinivasa Reddy Gumbula <gu...@hotmail.com> on 2001/03/21 17:23:57 UTC
Re: Sorry! was: RE: ISAPI Filter: Bug? in jk_isapi_plugin.c found andfixed
Hi!
Following the idea of the jason I fix the defect.
Since I cannot send the attachment. I am putting the
code that needs to be changed.
In the HttpFilterProc add these two lines after
p->SetHeader(pfc, "url", extension_uri);
p->AddHeader(pfc, "TOMCATURI:",uri);
p->AddHeader(pfc, "TOMCATWORKER:",worker);
And replace the else block of
if(from_filt){ } with the following code
in the init_ws_service:
else {
// code added by srini
char *uri = (char*)malloc(1024*sizeof(char));
char *worker = (char*)malloc(1024*sizeof(char));
int bufSize;
jk_log(logger, JK_LOG_DEBUG, "filter_ext_record_t is NULL:\n");
private_data->lpEcb->GetServerVariable(private_data->lpEcb->ConnID,"HTTP_TOMCATURI",uri,&bufSize);
jk_log(logger, JK_LOG_DEBUG, "uri %s:\n",uri);
private_data->lpEcb->GetServerVariable(private_data->lpEcb->ConnID,"HTTP_TOMCATWORKER",worker,&bufSize);
jk_log(logger, JK_LOG_DEBUG, "worker %s:\n",worker);
if(uri[0]!='\0'){
char *t = strchr(uri, '?');
if(t) {
*t = '\0';
t++;
if(!strlen(t)) {
t = NULL;
}
s->query_string = t;
s->req_uri = uri;
*worker_name = worker;
jk_log(logger, JK_LOG_DEBUG, "worker_name %s: \n",*worker_name);
jk_log(logger, JK_LOG_DEBUG, "s->req_uri %s: \n",s->req_uri);
}
} else {
s->query_string = private_data->lpEcb->lpszQueryString;
*worker_name = JK_AJP12_WORKER_NAME;
GET_SERVER_VARIABLE_VALUE("URL", s->req_uri);
}
//end
}
Thanks,
Srini.
-----------------
Jason,
Send me (shachor@il.ibm.com and shachor@tx.technion.ac.il) the bug fix
directly and I will
check it in
Also, thank you very much for the class A bug report + fix.
Gal Shachor
Jason Reid wrote:
>
>Ok, well, I guess I can't attach the source code to the
>bugfix. That's pretty embarrassing. Sorry to flood the
>list.
>
>For anyone that wants the modified source file, I can email it
>directly.
>
> > Jason Reid
> Technical Consultant
> AGENCY.COM
> 100 Woodbridge Center Drive, Suite 102
> Woodbridge, NJ 07095
> Email: jreid@agency.com
> <http://www.agency.com>
>
> "Do not meddle in the affairs of programmers,
> for they are subtle and quick to anger."
>
> > -----Original Message-----
> > From: Jason Reid [<ma...@agency.com>]
> > Sent: Friday, May 12, 2000 10:02 AM
> > To: 'tomcat-dev@jakarta.apache.org'
> > Subject: FW: ISAPI Filter: Bug? in jk_isapi_plugin.c found and fixed
> >
> >
> > Hi, I tried sending this directly to Gal Schacor,
> > but the message was unable to be successfully
> > delivered, so I decided to forward it onto
> > Tomcat-Dev.
> >
> > > Jason Reid
> > Technical Consultant
> > AGENCY.COM
> > 100 Woodbridge Center Drive, Suite 102
> > Woodbridge, NJ 07095
> > Email: jreid@agency.com
> > <http://www.agency.com>
> >
> > "Do not meddle in the affairs of programmers,
> > for they are subtle and quick to anger."
> >
> >
> > -----Original Message-----
> > From: Jason Reid
> > Sent: Friday, May 12, 2000 9:49 AM
> > To: 'schacor@il.ibm.com'
> > Subject: ISAPI Filter: Bug? in jk_isapi_plugin.c found and fixed
> >
> >
> > Hi,
> >
> > I recently posted a message to tomcat-dev describing a
> > problem I had with IIS + Tomcat...that message has been
> > attached to the end of this one.
> >
> > Anyway, I traced the behavior to the isapi filter,
> > did some logging, and found what I think was the problem.
> > In the comments, you say that the plugin uses a TLS to
> > pass values from the filter to the extension.
> >
> > In the filter, the filter_ext_record_t rec was always
> > being successfully stored in the Tls. However, in the
> > extension (function init_ws_service), sometimes the
> > TlsGetValue would return NULL.
> >
> > Now, I don't know very much about programming C in
> > Windows, and I know even less about doing ISAPI Filters
> > and Extensions (yesterday was actually the first time
> > I'd even seen one!). But I was left to assume that
> > perhaps a separate thread was invoking the extension then
> > had invoked the filter? And in that case, I gathered,
> > the TlsGetValue would not find the filter_ext_record that
> > had been previously stored.
> >
> > I went through Microsoft's Knowledge base, and found an
> > article on passing information from a Filter to an Extension.
> > One technique they suggested was the use of shared memory
> > blocks...I didn't want to introduce that sort of complexity.
> > However, for simple data values, the article said you could
> > also just add an Http header in the filter, which could be
> > read by the extension. So I hacked in behavior for the
> > filter to add two headers, TOMCATURI and TOMCATWORKER
> > as a substitute for the values kept in the filter_ext_record.
> > I also modified init_ws_service to accept an LPEXTENSION_CONTROL_BLOCK
> > parameter, which it could use to get at the headers.
> >
> > Using this technique for passing information, I was able to make
> > the bug disappear.
> >
> > I've attached the modified jk_isapi_plugin.c for your perusal.
> > If it looks a bit like a late-night hack, that's because it
> > is one :)
> >
> > > Jason Reid
> > Technical Consultant
> > AGENCY.COM
> > 100 Woodbridge Center Drive, Suite 102
> > Woodbridge, NJ 07095
> > Email: jreid@agency.com
> > <http://www.agency.com>
> >
> > "Do not meddle in the affairs of programmers,
> > for they are subtle and quick to anger."
> >
> >
> > -----Original Message-----
> > From: Jason Reid
> > Sent: Thursday, May 11, 2000 3:57 PM
> > To: 'tomcat-dev@jakarta.apache.org'
> > Subject: FW: Somewhat reproducable bug with POST
> >
> >
> > I posted this problem to tomcat-users a few days ago, but couldn't
> > really get any help. After delving into the problem a little bit
> > more, I think I was able to isolate the bad behavior to the
> > isapi_redirect.dll.
> >
> > On some occasions, when I try to post to a servlet running alongside
> > IIS, I get a 404 error. If I do a refresh/repost of form data,
> > the servlet executes fine the second time.
> >
> > After delving into the Ajp12 handler source, I discovered that I
> > could log the AJP details.
> >
> > I then visited the web application, and was able to capture the
> > logs of the error and then the subsequent success. The AJP logs
> > for the two were identical, except for the URIs. For the good
> > request, the 2 URI lines that were logged looked like:
> >
> > AJP: URI: /app/servlet/controller/SubscriberProfile CP:null LP:null
> >
> > For the bad request, however, the log showed:
> >
> > AJP: URI: /jakarta/isapi_redirect.dll CP:null LP:null
> >
> > Anyway, this bug is pretty much a showstopper for me, so I'm going
> > to delve into the C code and see if I can't turn anything up.
> > If, however, this catches the eye of anyone who is already familiar
> > with the code, and you have an idea of what might be occurring, I'd
> > appreciate any help you could give me.
> >
> >
> > > Jason Reid
> > Technical Consultant
> > AGENCY.COM
> > 100 Woodbridge Center Drive, Suite 102
> > Woodbridge, NJ 07095
> > Email: jreid@agency.com
> > <http://www.agency.com>
> >
> > "Do not meddle in the affairs of programmers,
> > for they are subtle and quick to anger."
> >
> >
> > -----Original Message-----
> > From: Jason Reid
> > Sent: Monday, May 08, 2000 7:14 PM
> > To: 'tomcat-user@jakarta.apache.org'
> > Subject: Somewhat reproducable bug with POST
> >
> >
> > I have Tomcat 3.1 hooked into IIS.
> >
> > One "super-servlet" intercepts all requests made into
> > my system, reads the extra path info, and then dispatches
> > the request to another servlet.
> >
> > Many of my servlets have their doGet() display a
> > page, with a form action that points to the servlet's
> > doPost(). This doPost(), after checking the input,
> > would dispatch the request to another servlet, or it
> > may simply call its own doGet().
> >
> > Sometimes, however, when on the page displayed by the
> > original doGet, form submission does not work as planned.
> > Instead, I will get a message of the following form:
> >
> > Error: 400
> > Location: /jakarta/isapi_redirect.dll
> > HTTP method POST is not supported by this URL
> >
> > If I do a refresh right after getting this message, it
> > works fine. It's also not entirely reproducable...sometimes
> > the process works without a hitch, sometimes it doesn't. Oh,
> > and it only seems to happen under the various flavors of IE.
> >
> > I have tried everything that I can think of...I've tried
> > modifying the "super-servlet", the individual processing
> > servlets themselves...nothing seems to work. I was wondering
> > if anyone could help me find the cause of this bug...does
> > anyone know under what conditions this sort of message would
> > be returned? Any help would be greatly appreciated...I'm at my
> > wits end.
> >
> > > Jason Reid
> > Technical Consultant
> > AGENCY.COM
> > 100 Woodbridge Center Drive, Suite 102
> > Woodbridge, NJ 07095
> > Email: jreid@agency.com
> > <http://www.agency.com>
> >
> > "Do not meddle in the affairs of programmers,
> > for they are subtle and quick to anger."
> >
> >
> >
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com