Menu
▾
▴
cpp-netlib-devel — Developers Mailing List
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(52) |
Jun
(30) |
Jul
(17) |
Aug
(9) |
Sep
(4) |
Oct
(7) |
Nov
(11) |
Dec
(19) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
|
Feb
(1) |
Mar
(37) |
Apr
(28) |
May
(15) |
Jun
(28) |
Jul
(7) |
Aug
(125) |
Sep
(116) |
Oct
(85) |
Nov
(14) |
Dec
(6) |
| 2009 |
Jan
(11) |
Feb
(4) |
Mar
(5) |
Apr
|
May
(9) |
Jun
(5) |
Jul
(4) |
Aug
(40) |
Sep
(1) |
Oct
(19) |
Nov
(43) |
Dec
(45) |
| 2010 |
Jan
(76) |
Feb
(95) |
Mar
(3) |
Apr
(23) |
May
(39) |
Jun
(54) |
Jul
(6) |
Aug
(13) |
Sep
(12) |
Oct
(59) |
Nov
(53) |
Dec
(43) |
| 2011 |
Jan
(43) |
Feb
(44) |
Mar
(25) |
Apr
(23) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(5) |
Oct
(1) |
Nov
(2) |
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(6) |
Oct
|
Nov
|
Dec
|
|
From: Nelson, E. - 2 <eri...@ba...> - 2010-02-09 21:07:33
|
From: Glyn Matthews [mailto:gly...@gm...] Sent: Tuesday, February 09, 2010 3:56 PM > I counted 5 references to boost/asio.hpp in all our headers, not just in this file. I updated these to use the specific headers in each case in my own fork. It does seem to speed things up, but only a little. Thanks! |
|
From: Nelson, E. - 2 <eri...@ba...> - 2010-02-09 21:07:01
|
From: Jeroen Habraken Sent: Tuesday, February 09, 2010 4:04 PM > Next time, could you please also file an issue at http://github.com/mikhailberis/cpp-netlib/issues, things seem to have a tendency to be forgotten or get lost on the mailing >list, this will let us track them properly. Okay, I wanted to see what people thought about it first- don't want to presume I understand why things were done the way they were. Erik |
|
From: Jeroen H. <vex...@gm...> - 2010-02-09 21:04:05
|
Hi Erik, On Tue, Feb 9, 2010 at 21:00, Nelson, Erik - 2 <eri...@ba...> wrote: > I was working to reduce my compile time a little with v0.5, and I > noticed that network/protocol/http/impl/response.ipp pulls in asio.hpp > in order to get const_buffer. > asio.hpp #includes literally 50 other header files, but it seems like > boost/asio/buffer.hpp is the only one needed... any objection to > replacing > > #include <boost/asio.hpp> > > With > > #include <boost/asio/buffer.hpp> > > In network/protocol/http/impl/response.ipp? > > Thanks > > Erik Nelson > Next time, could you please also file an issue at http://github.com/mikhailberis/cpp-netlib/issues, things seem to have a tendency to be forgotten or get lost on the mailing list, this will let us track them properly. Jeroen |
|
From: Glyn M. <gly...@gm...> - 2010-02-09 20:56:23
|
Hi Erik, On 9 February 2010 21:00, Nelson, Erik - 2 <eri...@ba...>wrote: > I was working to reduce my compile time a little with v0.5, and I > noticed that network/protocol/http/impl/response.ipp pulls in asio.hpp > in order to get const_buffer. > asio.hpp #includes literally 50 other header files, but it seems like > boost/asio/buffer.hpp is the only one needed... any objection to > replacing > > #include <boost/asio.hpp> > > With > > #include <boost/asio/buffer.hpp> > > In network/protocol/http/impl/response.ipp? > I counted 5 references to boost/asio.hpp in all our headers, not just in this file. I updated these to use the specific headers in each case in my own fork. It does seem to speed things up, but only a little. Thanks, Glyn |
|
From: Nelson, E. - 2 <eri...@ba...> - 2010-02-09 20:01:11
|
I was working to reduce my compile time a little with v0.5, and I noticed that network/protocol/http/impl/response.ipp pulls in asio.hpp in order to get const_buffer. asio.hpp #includes literally 50 other header files, but it seems like boost/asio/buffer.hpp is the only one needed... any objection to replacing #include <boost/asio.hpp> With #include <boost/asio/buffer.hpp> In network/protocol/http/impl/response.ipp? Thanks Erik Nelson |
|
From: Dean M. B. <mik...@gm...> - 2010-02-09 17:10:45
|
Hi Jeroen, I apologize for not being able to respond to the list sooner, I've been busy between being father, husband, and part-time consultant+project manager lately. That said I try to keep on top of emails, and I've only been able to relax a bit now. Hopefully I'll be able to respond to emails quicker this time. That said please see below. On Sun, Feb 7, 2010 at 7:14 AM, Jeroen Habraken <vex...@gm...> wrote: > > I saw you've merged my changes to master, yet I'd have preferred if > you had waited for my pull request. I intended to add the > boost::optional changes to the API first, to catch the breaking in one > go, yet I'm honoured that you considered my code to be master-branch > ready. > Yup, no worries. That merge also included a few fixes in different places. I actually wasn't supposed to merge with master, but I was having some trouble merging to 0.6-devel directly, having your code branched from 0.5-devel. I decided since I've already merged 0.5-devel to master, I might as well merge your code to master. ;) > Unfortunately with the merge you've reintroduced issue #3, something I > hadn't patched as I was anticipating to merge upstream with my code > before a pull-request. I've now merged upstream with my fork and > issued a pull-request to fix this in the 0.6-devel branch, but it > should be merged with master too. > Yup, I overlooked this. Thanks for patching and catching that. We should have a test for that specific issue! :D (That said I think I've merged it already into head and 0.6-devel too). ;) > I'll also try to layout somewhat of roadmap for the URI code as some > of the things I've mentioned before still have to be done: > - A lot more tests need to be added +1 > - Documentation needs to be updated, and an the example should be > expanded to show the use of scheme() for example +1 > - Another API change is coming up, which will expose the optional > parameters as boost::optionals, instead of returning an empty default > value > +1 > On the longer term I'd like to get on the way with URI normalisation, > but it still needs some pondering on how this will fit in the current > code. Given the fact that 0.6 is planned for the end of February, my > initial plan would be to finish what I'd hoped to do for 0.5, namely > the three things above. > That sounds great. Please branch off of 0.6-devel this time so that further development takes advantage of the new stuff I'll be checking in sooner than later. I really should stop being project manager and just get back to engineer mode both in cpp-netlib and in my consulting gigs. I miss writing C++!!! :D > Yours, > Jeroen Habraken > Thanks again for all the work, I think I personally don't have the patience to deal with the intricacies of being RFC compliant at the URI layer unlike you and other contributors to the project. Have a good week ahead and I look forward to another pull request soon! :D -- Dean Michael Berris cplusplus-soup.com | twitter.com/deanberris linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com |
|
From: Jeroen H. <vex...@gm...> - 2010-02-06 23:14:36
|
Hi Dean, On Sat, Feb 6, 2010 at 09:47, Dean Michael Berris <mik...@gm...> wrote: > Hi Jeroen, > > On Fri, Feb 5, 2010 at 4:27 AM, Jeroen Habraken <vex...@gm...> wrote: >> >> Unfortunately it's been a while since you've heard from me but I've >> just committed a rewrite which turns the parser into a grammar. > > No worries. I'm looking at it right now and I'm having some trouble > merging to my local copy. I'll resolve issues locally first then see > if I can merge your implementation to master, and then pull it from my > 0.6-devel branch. > >> Michael Caisse brought this up, and it allows other people to reuse >> the Spirit URI rule inside their own parsers. Unfortunately the >> transition wasn't as easy as I initially anticipated, but Hartmut >> Kaiser has been a great help, thanks for answering all those >> questions! >> > > Cool. They're a great bunch of guys there at the Spirit Mailing list. :) > >> As a bonus I've included IPv4 support, and hope to add some smaller >> changes such as exposing the boost::optionals soon. I've had a shot at >> IPv6 support, but it's an enormous rule thus it'll require some >> optimisation. >> > > Sweet! We can worry about IPv6 later when the world starts catching up > and implementing it as the default instead of IPv4. :) > >> Yours, >> Jeroen Habraken >> >> P.S. Dean, could you please have a look at the current derived HTTP >> implementation, I'd really like to hear your opinion. >> > > I'll let you know if I find any glaring problems. > > Have a good day and you'd hopefully hear more from me soon. :) > > -- > Dean Michael Berris > cplusplus-soup.com | twitter.com/deanberris > linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com > I saw you've merged my changes to master, yet I'd have preferred if you had waited for my pull request. I intended to add the boost::optional changes to the API first, to catch the breaking in one go, yet I'm honoured that you considered my code to be master-branch ready. Unfortunately with the merge you've reintroduced issue #3, something I hadn't patched as I was anticipating to merge upstream with my code before a pull-request. I've now merged upstream with my fork and issued a pull-request to fix this in the 0.6-devel branch, but it should be merged with master too. I'll also try to layout somewhat of roadmap for the URI code as some of the things I've mentioned before still have to be done: - A lot more tests need to be added - Documentation needs to be updated, and an the example should be expanded to show the use of scheme() for example - Another API change is coming up, which will expose the optional parameters as boost::optionals, instead of returning an empty default value On the longer term I'd like to get on the way with URI normalisation, but it still needs some pondering on how this will fit in the current code. Given the fact that 0.6 is planned for the end of February, my initial plan would be to finish what I'd hoped to do for 0.5, namely the three things above. Yours, Jeroen Habraken |
|
From: Dean M. B. <mik...@gm...> - 2010-02-06 09:12:45
|
Hi guys,
If you intend to follow the cutting edge developments for cpp-netlib
you can go ahead and track the 0.6-devel branch from
mikhailberis/cpp-netlib -- for this 0.6 release I intend to check in
helpers for the server-side application development using the http
server template.
In case you intend to branch for your own development, please branch
from 0.6-devel now.
Also, I'll be working on the following:
- Asynchronous HTTP Client implementation
- Refactoring the message type system;
* Make the storage of message-related data its own type that
basic_message<> derives from.
* Support different type extension metafunctions to allow
different types for source, destination, headers, body instead of just
making the string type the extension point
* More tests on the message system
* Implementing different rendering methods that use a MIME handler
In case you want to contribute a client implementation, please sound
off now so that I can schedule the merging and testing throughout
February -- target release for 0.6 is the end of February.
Thanks in advance guys and I hope this helps!
--
Dean Michael Berris
cplusplus-soup.com | twitter.com/deanberris
linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com
|
|
From: Dean M. B. <mik...@gm...> - 2010-02-06 08:48:24
|
Hi Jeroen, On Fri, Feb 5, 2010 at 4:27 AM, Jeroen Habraken <vex...@gm...> wrote: > > Unfortunately it's been a while since you've heard from me but I've > just committed a rewrite which turns the parser into a grammar. No worries. I'm looking at it right now and I'm having some trouble merging to my local copy. I'll resolve issues locally first then see if I can merge your implementation to master, and then pull it from my 0.6-devel branch. > Michael Caisse brought this up, and it allows other people to reuse > the Spirit URI rule inside their own parsers. Unfortunately the > transition wasn't as easy as I initially anticipated, but Hartmut > Kaiser has been a great help, thanks for answering all those > questions! > Cool. They're a great bunch of guys there at the Spirit Mailing list. :) > As a bonus I've included IPv4 support, and hope to add some smaller > changes such as exposing the boost::optionals soon. I've had a shot at > IPv6 support, but it's an enormous rule thus it'll require some > optimisation. > Sweet! We can worry about IPv6 later when the world starts catching up and implementing it as the default instead of IPv4. :) > Yours, > Jeroen Habraken > > P.S. Dean, could you please have a look at the current derived HTTP > implementation, I'd really like to hear your opinion. > I'll let you know if I find any glaring problems. Have a good day and you'd hopefully hear more from me soon. :) -- Dean Michael Berris cplusplus-soup.com | twitter.com/deanberris linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com |
|
From: Jeroen H. <vex...@gm...> - 2010-02-05 16:48:53
|
Hi, On Fri, Feb 5, 2010 at 17:17, Nelson, Erik - 2 <eri...@ba...> wrote: > In the http server example, the request.uri is still escaped, e.g., has > characters like '%2f' in it... Is there a 'best' way to unescape it > within cpp-netlib? Or should I use another source of un-escaping? > > Thanks > > Erik > The short answer, no cpp-netlib currently doesn't have any features to unescape a URI except for an implementation of unescape itself. Now for the longer answer, as unescaping a URI isn't as easy as it might look at first glance. It is part of the normalisation process normally applied to URI's, and is described in section 6.2.2.2. in the RFC which can be found at http://www.ietf.org/rfc/rfc3986.txt. Each section of the URI has a set of reserved characters, and those should be left escaped whilst any other character can be unescaped safely. Unescaping the reserved characters would change the meaning of the URI, and might even make it invalid. An example would be http://user%40n...@do...d versus http://us...@na...@domain.tld, where the escaped character is in the user_info section, and unescaping it invalidates the URI. The whole normalisation process is something I hope to tackle after I've completed the parser, but I'm unsure when this might be. For the time being you could have a look at google-url, a URI parser written for the chrome browser which can be found at http://code.google.com/p/google-url/. Jeroen |
|
From: Nelson, E. - 2 <eri...@ba...> - 2010-02-05 16:18:46
|
In the http server example, the request.uri is still escaped, e.g., has characters like '%2f' in it... Is there a 'best' way to unescape it within cpp-netlib? Or should I use another source of un-escaping? Thanks Erik |
|
From: Nelson, E. - 2 <eri...@ba...> - 2010-02-04 22:31:51
|
Jeroen Habraken wrote: >You can call query() on a uri and http::uri to grab the query string, but >we currently don't have a parser for them yet. It's on my TODO list though. >You could give writing one yourself based on >http://boost-spirit.com/home/articles/qi-example/parsing-a-list-of-key- value-pairs-using-spirit-qi/ >a shot, it shouldn't be too hard. Okay, I'll see if I can put together something that works well enough. Thanks Erik |
|
From: Jeroen H. <vex...@gm...> - 2010-02-04 22:24:36
|
On Thu, Feb 4, 2010 at 23:18, Nelson, Erik - 2 <eri...@ba...> wrote: > Jeroen Habraken wrote: > >>Ah, in that case it makes sense, "/test?arg=5" is a relative URI, not > an >> absolute one, and something we decided not to support in the URI > parser. > > That's fair enough, though it does seem a little counter-intuitive that > the value in request.uri can't be parsed. Is there support in > cpp-netlib for digging out the arguments, or will I need to write my own > parser to grab things like 'arg=5'? > > Erik > You can call query() on a uri and http::uri to grab the query string, but we currently don't have a parser for them yet. It's on my TODO list though. You could give writing one yourself based on http://boost-spirit.com/home/articles/qi-example/parsing-a-list-of-key-value-pairs-using-spirit-qi/ a shot, it shouldn't be too hard. Jeroen |
|
From: Nelson, E. - 2 <eri...@ba...> - 2010-02-04 22:18:52
|
Jeroen Habraken wrote: >Ah, in that case it makes sense, "/test?arg=5" is a relative URI, not an > absolute one, and something we decided not to support in the URI parser. That's fair enough, though it does seem a little counter-intuitive that the value in request.uri can't be parsed. Is there support in cpp-netlib for digging out the arguments, or will I need to write my own parser to grab things like 'arg=5'? Erik |
|
From: Jeroen H. <vex...@gm...> - 2010-02-04 22:11:26
|
On Thu, Feb 4, 2010 at 23:05, Nelson, Erik - 2 <eri...@ba...> wrote: > Jeroen Habraken wrote: >>I can't reproduce this behaviour with the http::uri parser in netlib > 0.5, >>so I'm uncertain where this goes wrong. I've added the test as a > trivial >>example of how to use http::uri. > > Thanks, but a better test might be something like > > string test = "/test?arg=5"; > > since that's what request.uri produces in this case > > Erik > Ah, in that case it makes sense, "/test?arg=5" is a relative URI, not an absolute one, and something we decided not to support in the URI parser. Jeroen |
|
From: Nelson, E. - 2 <eri...@ba...> - 2010-02-04 22:05:42
|
Jeroen Habraken wrote: >I can't reproduce this behaviour with the http::uri parser in netlib 0.5, >so I'm uncertain where this goes wrong. I've added the test as a trivial >example of how to use http::uri. Thanks, but a better test might be something like string test = "/test?arg=5"; since that's what request.uri produces in this case Erik |
|
From: Jeroen H. <vex...@gm...> - 2010-02-04 21:48:27
|
Hi, On Thu, Feb 4, 2010 at 22:11, Nelson, Erik - 2 <eri...@ba...> wrote: > > On Thursday, February 04, 2010 3:33 PM Jeroen Habraken > [mailto:vex...@gm...] wrote: > >>There's this, > http://github.com/mikhailberis/cpp-netlib/blob/0.5/libs/network/example/ > uri.cpp >>which uses http::uri, but it isn't much. The URI tests might offer some > insight too, >>those can be found at > http://github.com/mikhailberis/cpp-netlib/blob/0.5/libs/network/test/url > _test.cpp. > > > Okay, I'm playing around with it a little bit... If I use a > URL like http://localhost:8000/test?arg=5 against the hello_world_server > example, and in the handler do something like > > boost::network::uri::http::uri http_uri(request.uri) > > the request.uri is something like "/test?arg=5" and http_uri.valid() is > false... Is this expected? I would have guessed that request.uri would > parse okay. Is there some support for pulling apart the query string > (separating the path from the arguments)? > > Thanks > > Erik > I can't reproduce this behaviour with the http::uri parser in netlib 0.5, so I'm uncertain where this goes wrong. I've added the test as a trivial example of how to use http::uri. Jeroen |
|
From: Glyn M. <gly...@gm...> - 2010-02-04 21:13:48
|
Hi Jeroen, On 4 February 2010 21:27, Jeroen Habraken <vex...@gm...> wrote: > > Unfortunately it's been a while since you've heard from me but I've > just committed a rewrite which turns the parser into a grammar. > Michael Caisse brought this up, and it allows other people to reuse > the Spirit URI rule inside their own parsers. Unfortunately the > transition wasn't as easy as I initially anticipated, but Hartmut > Kaiser has been a great help, thanks for answering all those > questions! > > As a bonus I've included IPv4 support, and hope to add some smaller > changes such as exposing the boost::optionals soon. I've had a shot at > IPv6 support, but it's an enormous rule thus it'll require some > optimisation. > > Excellent, thank you very much for this effort. I will take a closer look when I find time and will provide feedback later. Glyn |
|
From: Nelson, E. - 2 <eri...@ba...> - 2010-02-04 21:12:09
|
On Thursday, February 04, 2010 3:33 PM Jeroen Habraken [mailto:vex...@gm...] wrote: >There's this, http://github.com/mikhailberis/cpp-netlib/blob/0.5/libs/network/example/ uri.cpp >which uses http::uri, but it isn't much. The URI tests might offer some insight too, >those can be found at http://github.com/mikhailberis/cpp-netlib/blob/0.5/libs/network/test/url _test.cpp. Okay, I'm playing around with it a little bit... If I use a URL like http://localhost:8000/test?arg=5 against the hello_world_server example, and in the handler do something like boost::network::uri::http::uri http_uri(request.uri) the request.uri is something like "/test?arg=5" and http_uri.valid() is false... Is this expected? I would have guessed that request.uri would parse okay. Is there some support for pulling apart the query string (separating the path from the arguments)? Thanks Erik |
|
From: Nelson, E. - 2 <eri...@ba...> - 2010-02-04 20:39:05
|
On Thursday, February 04, 2010 3:33 PM Jeroen Habraken [mailto:vex...@gm...] wrote: >There's this, http://github.com/mikhailberis/cpp-netlib/blob/0.5/libs/network/example/ uri.cpp >which uses http::uri, but it isn't much. The URI tests might offer some insight too, >those can be found at http://github.com/mikhailberis/cpp-netlib/blob/0.5/libs/network/test/url _test.cpp. Thanks, that's helpful Erik |
|
From: Jeroen H. <vex...@gm...> - 2010-02-04 20:33:17
|
Hi, On Thu, Feb 4, 2010 at 21:21, Glyn Matthews <gly...@gm...> wrote: > Hi Erik, > > On 4 February 2010 21:13, Nelson, Erik - 2 <eri...@ba...> > wrote: >> >> I didn't see one in the hello_world_server example... am I looking in >> the wrong place? >> > > You're not, there isn't an HTTP URI example. > Glyn > There's this, http://github.com/mikhailberis/cpp-netlib/blob/0.5/libs/network/example/uri.cpp which uses http::uri, but it isn't much. The URI tests might offer some insight too, those can be found at http://github.com/mikhailberis/cpp-netlib/blob/0.5/libs/network/test/url_test.cpp. Jeroen |
|
From: Jeroen H. <vex...@gm...> - 2010-02-04 20:28:29
|
Hi, On Sat, Jan 9, 2010 at 16:13, Dean Michael Berris <mik...@gm...> wrote: > On Sat, Jan 9, 2010 at 11:05 PM, Jeroen Habraken <vex...@gm...> wrote: >> On Sat, Jan 9, 2010 at 15:51, Dean Michael Berris >> <mik...@gm...> wrote: >>> >>> Because currently the HTTP URI parses the string at construction time >>> (and URI's are immutable anyway), validity checks are as simple as >>> returning a boolean. So parse once, validity and data are available >>> right away once the object is constructed. >> >> This is indeed very nice, and should be kept this way, in what I'm >> proposing -with the exception of relative URI's, see below- will be >> kept that way, mere the place where most of the parsing is done will >> change. >> > > Alright. Let's just make sure that it does make sense and doesn't back > us into a corner. It's easy to change later on if we find that leaving > all the parsing into one parse function is too limiting (or too hard > to specialize). > >>> >>> If you are going to allow relative URI's, will that be valid for SMTP >>> too? What would be the host? >>> >> >> You're right, adding relative URI support will increase the complexity >> of the library more than I initially thought. I'm going to leave it >> out, at least for now. Implementing it later shouldn't be a problem if >> for any reason we choose to do so. >> > > If there is a good reason for us to support it then I don't have any > objection to it. Right now though I don't see it yet so I'm > apprehensive still. :) > >> >> Thank you for your thoughts, you might just have prevented me from >> overcomplicating things :) >> > > You're welcome. :) > > -- > Dean Michael Berris > cplusplus-soup.com | twitter.com/deanberris > linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com > Unfortunately it's been a while since you've heard from me but I've just committed a rewrite which turns the parser into a grammar. Michael Caisse brought this up, and it allows other people to reuse the Spirit URI rule inside their own parsers. Unfortunately the transition wasn't as easy as I initially anticipated, but Hartmut Kaiser has been a great help, thanks for answering all those questions! As a bonus I've included IPv4 support, and hope to add some smaller changes such as exposing the boost::optionals soon. I've had a shot at IPv6 support, but it's an enormous rule thus it'll require some optimisation. Yours, Jeroen Habraken P.S. Dean, could you please have a look at the current derived HTTP implementation, I'd really like to hear your opinion. |
|
From: Glyn M. <gly...@gm...> - 2010-02-04 20:21:47
|
Hi Erik, On 4 February 2010 21:13, Nelson, Erik - 2 <eri...@ba...>wrote: > I didn't see one in the hello_world_server example... am I looking in > the wrong place? > > You're not, there isn't an HTTP URI example. Glyn |
|
From: Nelson, E. - 2 <eri...@ba...> - 2010-02-04 20:13:52
|
I didn't see one in the hello_world_server example... am I looking in the wrong place? Erik |
|
From: Nelson, E. - 2 <eri...@ba...> - 2010-02-04 19:52:53
|
On Thursday, February 04, 2010 2:40 PM, Jeroen Habraken [mailto:vex...@gm...] wrote: > As it's a boost::optional<boost::uint16_t> it first checks whether a port is available in the uri_parts, this is the boolean operator of the optional, reflected by > "parts_.port", and if it is it will return it, "*(parts_.port)". Otherwise it will check the scheme and return > 443 if it is 'https' (case insensitve), and only if that's not the case it will return 80. Okay, thanks |
7 messages has been excluded from this view by a project administrator.
