Hi,
I'm still working on the port of the Url classes from Squeak to Dolphin, and I'm concerned by the https protocol. Apparently, the original classes don't support it. Should I make the class HttpUrl handle both http and https, or should I create a subclass for HttpsUrl? I don't know if there's enough difference to justify it. BTW, where can I find more info on the diffrences between the http and https protocols? Thanks |
Fernando,
> I'm still working on the port of the Url classes from Squeak to > Dolphin, and I'm concerned by the https protocol. Apparently, the > original classes don't support it. > > Should I make the class HttpUrl handle both http and https, or should > I create a subclass for HttpsUrl? I don't know if there's enough > difference to justify it. > > BTW, where can I find more info on the diffrences between the http and > https protocols? My understanding (with that and $4, you can get cup of coffee at Buckstop's<g>) is that https is http over an SSL connection. Aside from a valid OpenSSL mapping for Dolphin, authentication is probably more of a concern to you. IMHO, basic authentication is sufficient over an encrypted connection; I would never use it in the clear, but then I would never send anything needing authentication w/o SSL or other encryption. Have a good one, Bill -- Wilhelm K. Schwab, Ph.D. [hidden email] |
In reply to this post by Fernando Rodriguez
> Should I make the class HttpUrl handle both http and https, or should
> I create a subclass for HttpsUrl? I don't know if there's enough > difference to justify it. There isn't enough to justify it. The only difference between the two url schemes is the s infront. The browser / client handles the details. Unless your Url classes are forming part of an Http client? > BTW, where can I find more info on the diffrences between the http and > https protocols? https is http tunneled through a SSL/TSL connection. Quote from the RFC: "Conceptually, HTTP/TLS is very simple. Simply use HTTP over TLS precisely as you would use HTTP over TCP." |
Sean M wrote:
> > Should I make the class HttpUrl handle both http and https, or should > > I create a subclass for HttpsUrl? I don't know if there's enough > > difference to justify it. > > There isn't enough to justify it. The only difference between the two url > schemes is the s infront. The browser / client handles the details. > > Unless your Url classes are forming part of an Http client? From what Fernando's said (in other threads) I think these URL classes are more than just names of network resources. It sounds as if the Squeak code makes them responsible for managing network connections to the named resource too (which seems poor design to me, though I haven't looked at the code in question). If so, then not only will HttpsUrl have a different default port and different 'scheme' name (enough in itself to justify a separate class, IMO, unless that data is held in a table instead of in polymorphic methods), but will also need rather a lot of extra logic for setting up a connection. Incidentally, another reason to handle them as a different class has little to do with OO design per se. The HTTPS handling will introduce a dependency on whatever SSL package Fernando uses. It would be better to avoid making the HTTP dependent on the SSL stuff too, which suggests that they should be separate classes in separate packages. -- chris |
On Wed, 1 Jun 2005 09:41:59 +0100, "Chris Uppal"
<[hidden email]> wrote: >> >> There isn't enough to justify it. The only difference between the two url >> schemes is the s infront. The browser / client handles the details. >> >> Unless your Url classes are forming part of an Http client? > >From what Fernando's said (in other threads) I think these URL classes are more >than just names of network resources. It sounds as if the Squeak code makes >them responsible for managing network connections to the named resource too Yes, though I'm not sure if I like this part of the design... |
In reply to this post by Chris Uppal-3
Chris Uppal wrote:
> Sean M wrote: > > > > Should I make the class HttpUrl handle both http and https, or should > > > I create a subclass for HttpsUrl? I don't know if there's enough > > > difference to justify it. > > > > There isn't enough to justify it. The only difference between the two url > > schemes is the s infront. The browser / client handles the details. > > > > Unless your Url classes are forming part of an Http client? > > From what Fernando's said (in other threads) I think these URL classes are more > than just names of network resources. It sounds as if the Squeak code makes > them responsible for managing network connections to the named resource too > (which seems poor design to me, though I haven't looked at the code in > question). If so, then not only will HttpsUrl have a different default port > and different 'scheme' name (enough in itself to justify a separate class, IMO, > unless that data is held in a table instead of in polymorphic methods), but > will also need rather a lot of extra logic for setting up a connection. > > Incidentally, another reason to handle them as a different class has little to > do with OO design per se. The HTTPS handling will introduce a dependency on > whatever SSL package Fernando uses. It would be better to avoid making the > HTTP dependent on the SSL stuff too, which suggests that they should be > separate classes in separate packages. Visual Works 7.3 has moved from separate classes for http and https protocols to one class HTTPClient that handles both cases. HTTPClient determines context from the url protocol. And AFAICR it is the connection from client to server that is the specialisated to handle SSL. I guess you know about OpenSSL and are planning to link to their DDLs? Edward Stow > > -- chris |
> I guess you know about OpenSSL and are planning to link to their DDLs?
Actually Chris Double already wrote a SecureSocket for Dolphin http://www.double.co.nz/smalltalk/ It's for 4.0, but should "Just Work" in 5 I guess |
Free forum by Nabble | Edit this page |