You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Ryan Bloom <rb...@raleigh.ibm.com> on 2000/01/11 18:23:25 UTC
Annoying unusual bug.
This bug was reported to me, and although I have a solution, I think it
should be pushed off to 2.0. I am looking for any other ideas for how to
fix this.
The basic bug is that a https request is made without a trailing slash,
which causes a redirect, and on that page a cookie is set. When Apache
creates the url for the redirect, it will automatically append the port
number if it is not port 80. This causes Netscape to assocaite the cookie
with the full hostname with the port appended, and when the user goes to
the next page, the cookie is forgotten. For example:
request is made to:
https://abc.com/admin
Apache causes a redirect to:
https://abc.com:443/admin/
The cookie is assocaited with abc.com:443 and when the user clicks on a
link and requests https://abc.com/admin/page1, the cookie is ignored.
This is a VERY unusual set of circumstances, but I think it should be
fixed. The obvious solution to me, was to allow modules to register
protocols and default ports. When we create a redirection url, if the
default port for the current protocol is used, we leave off the port
number. The problem, we don't record the protocol in the request_rec.
So, my solution:
add a char *protocol to the request_rec, and have it default to http.
When the request comes in, if it is anything else, we overwrite this
default. This also keeps the SSL modules from having to provide this
field in the record (I have been told most of them provide it, but I
haven't checked yet). This would allow us to register the protocols, and
the rest of the algorithm works properly.
Any other thoughts? If not, I will implement this for Apache 2.0 very
soon.
Ryan
_______________________________________________________________________
Ryan Bloom rbb@raleigh.ibm.com
4205 S Miami Blvd
RTP, NC 27709
Come to the first official Apache Software Foundation
Conference! <http://ApacheCon.Com/>
Re: Annoying unusual bug.
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
> Terminology alert: HTTPS (not SSL) uses 443, and is not tunneled over
> HTTP - its the other way around.
Okay, so I got a few things backwards. :-)
Regardless, I have a patch, but in creating it, I realized that Apache 2.0
already had the default_port hook implemented. Apache 1.3 doesn't have
this function. I probably should have checked to make sure Apache 2.0 had
the same bug, but I didn't. :-)
I am still not convinced a module hook is the right way to implement this,
but since it was already done, I am going to leave it alone for now.
The two implementations are almost equivalent, but I think the module hook
is overkill. Just MHO.
Ryan
_______________________________________________________________________
Ryan Bloom rbb@raleigh.ibm.com
4205 S Miami Blvd
RTP, NC 27709
Come to the first official Apache Software Foundation
Conference! <http://ApacheCon.Com/>
Re: Annoying unusual bug.
Posted by Ben Laurie <be...@algroup.co.uk>.
Ryan Bloom wrote:
>
> > > I don't know what integer should be returned, I know that each module will
> > > have an opportunity to register their own port numbers.
> >
> > What I'm saying is that a protocol doesn't necessarily translate to a
> > single port number.
>
> But if a protocol doesn't translate to a specified set of port numbers,
> then the port number is dynamic and needs to be sent to the client app.
> The purpose of this patch is to realize that for any protocol tunneled
> over http, there is a specified default port (eg SSL uses 443).
Terminology alert: HTTPS (not SSL) uses 443, and is not tunneled over
HTTP - its the other way around.
> We do not
> want to re-specify that port to the client app as long as it is the
> default. I think you are making things a bit too compicated here. The
> patch is coming soon so we can discuss specifics much easier.
I can live with it the way you suggest until I find an example that's
the other way :-)
Cheers,
Ben.
--
SECURE HOSTING AT THE BUNKER! http://www.thebunker.net/hosting.htm
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
Re: Annoying unusual bug.
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
> > I don't know what integer should be returned, I know that each module will
> > have an opportunity to register their own port numbers.
>
> What I'm saying is that a protocol doesn't necessarily translate to a
> single port number.
But if a protocol doesn't translate to a specified set of port numbers,
then the port number is dynamic and needs to be sent to the client app.
The purpose of this patch is to realize that for any protocol tunneled
over http, there is a specified default port (eg SSL uses 443). We do not
want to re-specify that port to the client app as long as it is the
default. I think you are making things a bit too compicated here. The
patch is coming soon so we can discuss specifics much easier.
Ryan
_______________________________________________________________________
Ryan Bloom rbb@raleigh.ibm.com
4205 S Miami Blvd
RTP, NC 27709
Come to the first official Apache Software Foundation
Conference! <http://ApacheCon.Com/>
Re: Annoying unusual bug.
Posted by Ben Laurie <be...@algroup.co.uk>.
rbb@apache.org wrote:
>
> > > I don't think it should be a hook. Why should multiple modules implement
> > > a function that basically returns an integer?
> >
> > How do you know, in general, what integer should be returned? I'll admit
> > I may be overcomplicating it, but I'm not convinced.
>
> I don't know what integer should be returned, I know that each module will
> have an opportunity to register their own port numbers.
What I'm saying is that a protocol doesn't necessarily translate to a
single port number.
Cheers,
Ben.
--
SECURE HOSTING AT THE BUNKER! http://www.thebunker.net/hosting.htm
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
Re: Annoying unusual bug.
Posted by rb...@apache.org.
> > I don't think it should be a hook. Why should multiple modules implement
> > a function that basically returns an integer?
>
> How do you know, in general, what integer should be returned? I'll admit
> I may be overcomplicating it, but I'm not convinced.
I don't know what integer should be returned, I know that each module will
have an opportunity to register their own port numbers.
>
> > Plus, how would we know
> > which protocol module should be used? We don't want to check if the port
> > used is a default for ANY known protocol, we really want to know if the
> > current port is the default port for the current protocol.
>
> Exactly, so only the protocol module for the current protocol should
> return a value. Could be that we want a function pointer rather than an
> integer or a hook, to achieve complete generality.
I think we are saying the same thing in a different way. I have most of
the code implemented, let me finish it up tomorrow and post a patch, and
you can comment on that rather than trying to express it in words. :-)
I implemented it before I ever posted in the hopes of getting it into 1.3,
but the changes ended up being too big to really make sense for 1.3.
Ryan
Re: Annoying unusual bug.
Posted by Ben Laurie <be...@algroup.co.uk>.
Ryan Bloom wrote:
>
> > > So, my solution:
> > > add a char *protocol to the request_rec, and have it default to http.
> > > When the request comes in, if it is anything else, we overwrite this
> > > default. This also keeps the SSL modules from having to provide this
> > > field in the record (I have been told most of them provide it, but I
> > > haven't checked yet). This would allow us to register the protocols, and
> > > the rest of the algorithm works properly.
> > >
> > > Any other thoughts? If not, I will implement this for Apache 2.0 very
> > > soon.
> >
> > Yeah. It should be a hook, surely? In Apache-SSL, ap_default_port(r)
> > determines the appropriate port (by examining stuff in the conn_rec,
> > ISTR), but the generic way is for ap_default_port() to be a hook, and
> > for protocol modules to hook it.
>
> I don't think it should be a hook. Why should multiple modules implement
> a function that basically returns an integer?
How do you know, in general, what integer should be returned? I'll admit
I may be overcomplicating it, but I'm not convinced.
> Plus, how would we know
> which protocol module should be used? We don't want to check if the port
> used is a default for ANY known protocol, we really want to know if the
> current port is the default port for the current protocol.
Exactly, so only the protocol module for the current protocol should
return a value. Could be that we want a function pointer rather than an
integer or a hook, to achieve complete generality.
> I was basically
> going to:
>
> add ap_register_protocol(proto, port) /* adds info to a global table*/
> in ap_construct_url grab the default port from the global table and check
> it against the current port.
Well, it occurs to me that this doesn't work when ports are dynamically
allocated (e.g. FTP data connections, RTP/RTSP stuff, and so on).
> I think the ap_register_protocol function should be called from the
> register_hooks functions, but it should not be implemented like the other
> hooks are.
I think it should be:
void ap_register_protocol(const char *proto,int
(*get_default_port)(request_rec *r));
Cheers,
Ben.
--
SECURE HOSTING AT THE BUNKER! http://www.thebunker.net/hosting.htm
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
Re: Annoying unusual bug.
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
> > So, my solution:
> > add a char *protocol to the request_rec, and have it default to http.
> > When the request comes in, if it is anything else, we overwrite this
> > default. This also keeps the SSL modules from having to provide this
> > field in the record (I have been told most of them provide it, but I
> > haven't checked yet). This would allow us to register the protocols, and
> > the rest of the algorithm works properly.
> >
> > Any other thoughts? If not, I will implement this for Apache 2.0 very
> > soon.
>
> Yeah. It should be a hook, surely? In Apache-SSL, ap_default_port(r)
> determines the appropriate port (by examining stuff in the conn_rec,
> ISTR), but the generic way is for ap_default_port() to be a hook, and
> for protocol modules to hook it.
I don't think it should be a hook. Why should multiple modules implement
a function that basically returns an integer? Plus, how would we know
which protocol module should be used? We don't want to check if the port
used is a default for ANY known protocol, we really want to know if the
current port is the default port for the current protocol. I was basically
going to:
add ap_register_protocol(proto, port) /* adds info to a global table*/
in ap_construct_url grab the default port from the global table and check
it against the current port.
I think the ap_register_protocol function should be called from the
register_hooks functions, but it should not be implemented like the other
hooks are.
Ryan
_______________________________________________________________________
Ryan Bloom rbb@raleigh.ibm.com
4205 S Miami Blvd
RTP, NC 27709
Come to the first official Apache Software Foundation
Conference! <http://ApacheCon.Com/>
Re: Annoying unusual bug.
Posted by Ben Laurie <be...@algroup.co.uk>.
Ryan Bloom wrote:
>
> This bug was reported to me, and although I have a solution, I think it
> should be pushed off to 2.0. I am looking for any other ideas for how to
> fix this.
>
> The basic bug is that a https request is made without a trailing slash,
> which causes a redirect, and on that page a cookie is set. When Apache
> creates the url for the redirect, it will automatically append the port
> number if it is not port 80. This causes Netscape to assocaite the cookie
> with the full hostname with the port appended, and when the user goes to
> the next page, the cookie is forgotten. For example:
>
> request is made to:
> https://abc.com/admin
>
> Apache causes a redirect to:
> https://abc.com:443/admin/
>
> The cookie is assocaited with abc.com:443 and when the user clicks on a
> link and requests https://abc.com/admin/page1, the cookie is ignored.
>
> This is a VERY unusual set of circumstances, but I think it should be
> fixed. The obvious solution to me, was to allow modules to register
> protocols and default ports. When we create a redirection url, if the
> default port for the current protocol is used, we leave off the port
> number. The problem, we don't record the protocol in the request_rec.
>
> So, my solution:
> add a char *protocol to the request_rec, and have it default to http.
> When the request comes in, if it is anything else, we overwrite this
> default. This also keeps the SSL modules from having to provide this
> field in the record (I have been told most of them provide it, but I
> haven't checked yet). This would allow us to register the protocols, and
> the rest of the algorithm works properly.
>
> Any other thoughts? If not, I will implement this for Apache 2.0 very
> soon.
Yeah. It should be a hook, surely? In Apache-SSL, ap_default_port(r)
determines the appropriate port (by examining stuff in the conn_rec,
ISTR), but the generic way is for ap_default_port() to be a hook, and
for protocol modules to hook it.
Cheers,
Ben.
--
SECURE HOSTING AT THE BUNKER! http://www.thebunker.net/hosting.htm
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
Re: Annoying unusual bug.
Posted by Greg Stein <gs...@lyra.org>.
On Tue, 11 Jan 2000, Ryan Bloom wrote:
> > > Any other thoughts? If not, I will implement this for Apache 2.0 very
> > > soon.
> >
> > I would say to use your approach for 2.0. In the 1.3 series, I'd recommend
> > *against* altering request_rec and just hard-code recognition of the 443
> > port.
> >
> > In other words: minimal change to 1.3 to fix the problem since we're
> > "doing it right" in the 2.0 series.
>
> I was actually going to skip this completely for 1.3, and only implement
> it for 2.0. I figure the case is so unusual that we can ignore it in 1.3
> until somebody actually submits a bug. The people who found the original
> problem are going to just hack their side of things to make it work.
Well then... +1! :-)
-g
--
Greg Stein, http://www.lyra.org/
Re: Annoying unusual bug.
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
> > Any other thoughts? If not, I will implement this for Apache 2.0 very
> > soon.
>
> I would say to use your approach for 2.0. In the 1.3 series, I'd recommend
> *against* altering request_rec and just hard-code recognition of the 443
> port.
>
> In other words: minimal change to 1.3 to fix the problem since we're
> "doing it right" in the 2.0 series.
I was actually going to skip this completely for 1.3, and only implement
it for 2.0. I figure the case is so unusual that we can ignore it in 1.3
until somebody actually submits a bug. The people who found the original
problem are going to just hack their side of things to make it work.
Ryan
_______________________________________________________________________
Ryan Bloom rbb@raleigh.ibm.com
4205 S Miami Blvd
RTP, NC 27709
Come to the first official Apache Software Foundation
Conference! <http://ApacheCon.Com/>
Re: Annoying unusual bug.
Posted by Greg Stein <gs...@lyra.org>.
On Tue, 11 Jan 2000, Ryan Bloom wrote:
>...
> This is a VERY unusual set of circumstances, but I think it should be
> fixed. The obvious solution to me, was to allow modules to register
> protocols and default ports. When we create a redirection url, if the
> default port for the current protocol is used, we leave off the port
> number. The problem, we don't record the protocol in the request_rec.
>
> So, my solution:
> add a char *protocol to the request_rec, and have it default to http.
> When the request comes in, if it is anything else, we overwrite this
> default. This also keeps the SSL modules from having to provide this
> field in the record (I have been told most of them provide it, but I
> haven't checked yet). This would allow us to register the protocols, and
> the rest of the algorithm works properly.
>
> Any other thoughts? If not, I will implement this for Apache 2.0 very
> soon.
I would say to use your approach for 2.0. In the 1.3 series, I'd recommend
*against* altering request_rec and just hard-code recognition of the 443
port.
In other words: minimal change to 1.3 to fix the problem since we're
"doing it right" in the 2.0 series.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/