Hi all,
I'm planning to make some changes to the Scheme class.
In HttpClient I need to decide whether a route requires
tunnelling, which depends on the socket factory for the
target host scheme, that's why I want to change it now.
There are two things I don't like:
1. The static map of registered schemes. Let's replace
it with a new SchemeSet class that can be instantiated
dynamically. A static default SchemeSet can still be
kept for fallbacks.
2. A scheme ID is not required to match the name:
Scheme s = new Scheme("http",,80);
Scheme.registerScheme("http", s);
Scheme.registerScheme("https", s);
String id = "https";
if (!Scheme.getScheme(id).getName().equals(id))
System.out.println("I am confused");
I'd give the new SchemeSet class a register(Scheme)
method that uses the scheme name as identifier.
objections?
cheers,
Roland
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: httpcomponents-dev-help (AT) jakarta (DOT) apache.org

Sun, 2007-01-28 at 10:30 +0100, Roland Weber wrote:
Hi all,

I'm planning to make some changes to the Scheme class.
In HttpClient I need to decide whether a route requires
tunnelling, which depends on the socket factory for the
target host scheme, that's why I want to change it now.
There are two things I don't like:

1. The static map of registered schemes. Let's replace
it with a new SchemeSet class that can be instantiated
dynamically. A static default SchemeSet can still be
kept for fallbacks.

SchemeRegistry maybe?

2. A scheme ID is not required to match the name:

Scheme s = new Scheme("http",,80);
Scheme.registerScheme("http", s);
Scheme.registerScheme("https", s);

String id = "https";
if (!Scheme.getScheme(id).getName().equals(id))
System.out.println("I am confused");

I'd give the new SchemeSet class a register(Scheme)
method that uses the scheme name as identifier.

I think scheme ID is still needed, if we want to be able to support
custom scheme aliases. Aliased schemes can be very handy when dealing
with different SSL contexts, for instance.

myhttps1 (some custom SSL settings) -https
myhttps2 (some other custom SSL settings) -https

objections?

Go for it.

cheers,
Roland

To unsubscribe, e-mail: httpcomponents-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: httpcomponents-dev-help (AT) jakarta (DOT) apache.org

To unsubscribe, e-mail: httpcomponents-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: httpcomponents-dev-help (AT) jakarta (DOT) apache.org

Hi ,

SchemeRegistry maybe?

Yes, that's better.

I think scheme ID is still needed, if we want to be able to support
custom scheme aliases. Aliased schemes can be very handy when dealing
with different SSL contexts, for instance.

myhttps1 (some custom SSL settings) -https
myhttps2 (some other custom SSL settings) -https

Where would the Scheme ID (or rather name) come into play?
Is there some URL transformation logic in HttpClient 3 that
would change myhttps1:// into https:// after the scheme (or
Protocol in 3.x) is looked up? Then I'll have to find a place
for that, too.

If we find it necessary, I'll add a

void registerAlias(String alias, Scheme schm)

to the SchemeRegistry class. That would give us a good place
for explanatory JavaDocs.

cheers,
Roland

To unsubscribe, e-mail: httpcomponents-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: httpcomponents-dev-help (AT) jakarta (DOT) apache.org

Mon, 2007-01-29 at 16:52 +0100, Roland Weber wrote:
Hi ,

SchemeRegistry maybe?

Yes, that's better.

I think scheme ID is still needed, if we want to be able to support
custom scheme aliases. Aliased schemes can be very handy when dealing
with different SSL contexts, for instance.

myhttps1 (some custom SSL settings) -https
myhttps2 (some other custom SSL settings) -https

Where would the Scheme ID (or rather name) come into play?

Roland,

It is necessary when sending requests through a non-transparent proxy,
where a full request URI is required.

Is there some URL transformation logic in HttpClient 3 that
would change myhttps1:// into https:// after the scheme (or
Protocol in 3.x) is looked up? Then I'll have to find a place
for that, too.

If we find it necessary, I'll add a

void registerAlias(String alias, Scheme schm)

to the SchemeRegistry class. That would give us a good place
for explanatory JavaDocs.

cheers,
Roland

To unsubscribe, e-mail: httpcomponents-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: httpcomponents-dev-help (AT) jakarta (DOT) apache.org

To unsubscribe, e-mail: httpcomponents-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: httpcomponents-dev-help (AT) jakarta (DOT) apache.org

Hi ,

myhttps1 (some custom SSL settings) -https
myhttps2 (some other custom SSL settings) -https
>Where would the Scheme ID (or rather name) come into play?

It is necessary when sending requests through a non-transparent proxy,
where a full request URI is required.

I thought we were just putting the full request URL into the
request line. But that of course can't be (the only way),
because HttpClient can be used with server-relative URLs.
For those, a full URL needs to be constructed.

I never understood where that relative URL idea came from.
Should we support it in 4.0 as well, or is it one of those
strange things we'd like to get rid of? It's not hard to
implement, so this is really a question of API design.

cheers,
Roland

To unsubscribe, e-mail: httpcomponents-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: httpcomponents-dev-help (AT) jakarta (DOT) apache.org

Tue, 2007-01-30 at 18:42 +0100, Roland Weber wrote:
Hi ,

Hi Roland,

myhttps1 (some custom SSL settings) -https
myhttps2 (some other custom SSL settings) -https
>Where would the Scheme ID (or rather name) come into play?

It is necessary when sending requests through a non-transparent proxy,
where a full request URI is required.

I thought we were just putting the full request URL into the
request line. But that of course can't be (the only way),
because HttpClient can be used with server-relative URLs.
For those, a full URL needs to be constructed.

I never understood where that relative URL idea came from.

It is horrible hangover from the early HttpClient 2.0 BETA2 days

Should we support it in 4.0 as well, or is it one of those
strange things we'd like to get rid of? It's not hard to
implement, so this is really a question of API design.

I really would love to get rid of it.

cheers,
Roland

To unsubscribe, e-mail: httpcomponents-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: httpcomponents-dev-help (AT) jakarta (DOT) apache.org

To unsubscribe, e-mail: httpcomponents-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: httpcomponents-dev-help (AT) jakarta (DOT) apache.org

Hi ,

I'll leave the relative URL stuff aside, though we'll
probably end up with something very similar if the API
remains the way I'm sketching it. We just won't tell
anybody if it's still working :-)
For the time being, I will also leave the scheme alias
thing aside. It's very simple to add later if we feel
that we need it and have a clearer understanding of
which parts of the code are affected.

cheers,
Roland

To unsubscribe, e-mail: httpcomponents-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: httpcomponents-dev-help (AT) jakarta (DOT) apache.org