Thank you Peter!
With some manual testing, it's working like expected here.
K.
On Sat, Jun 14, 2014 at 3:11 PM, Peter Bex peter@xs4all.nl wrote:
On Sat, Jun 07, 2014 at 02:19:22PM +0200, Peter Bex wrote:
So here's a new poll:
a) The current behaviour of resetting port to #f if it's
On Sat, Jun 07, 2014 at 02:19:22PM +0200, Peter Bex wrote:
So here's a new poll:
a) The current behaviour of resetting port to #f if it's the default port
for this scheme is ok.
b) The port should not be reset, and the uri should be printed with an
explicit port, even if it's the
If we go for (b), we could also provide a normalize-uri-port which sets it
to #f if it's already equal to the default port of its scheme. And perhaps
an optional normalize? argument to the uri-string procedure?
K.
On Sun, Jun 8, 2014 at 8:16 PM, Evan Hanson ev...@foldling.org wrote:
On
On Sat, Jun 07, 2014 at 09:01:01PM -0400, John Cowan wrote:
Peter Bex scripsit:
c) The port should not be reset, but the uri should be printed without
port if it's the default for this scheme.
+1 for (c).
hm, but if you really want to print http://foo:80/blabla, how
should that
Peter Bex scripsit:
hm, but if you really want to print http://foo:80/blabla, how
should that work?
Why would you? It means exactly the same thing as http://foo/blabla
and it's longer.
--
John Cowan http://www.ccil.org/~cowanco...@ccil.org
Go, and never darken my towels
Hi,
So here's a new poll:
a) The current behaviour of resetting port to #f if it's the default port
for this scheme is ok.
b) The port should not be reset, and the uri should be printed with an
explicit port, even if it's the default for this scheme.
c) The port should not be reset,
On 2014-06-08 11:14, Peter Bex wrote:
On Sat, Jun 07, 2014 at 09:01:01PM -0400, John Cowan wrote:
Peter Bex scripsit:
c) The port should not be reset, but the uri should be printed without
port if it's the default for this scheme.
+1 for (c).
hm, but if you really want to
On Wed, May 28, 2014 at 11:18:14AM +0200, Kristian Lein-Mathisen wrote:
I realize I already put down my vote, but I'd like to promote my case after
some thought. I guess what we're trying to find out is what's more
troublesome and/or surprising:
1. having to set the port explicitly (to #f?)
Peter Bex scripsit:
c) The port should not be reset, but the uri should be printed without
port if it's the default for this scheme.
+1 for (c).
--
John Cowan http://www.ccil.org/~cowanco...@ccil.org
Is a chair finely made tragic or comic? Is the portrait of Mona Lisa
I realize I already put down my vote, but I'd like to promote my case after
some thought. I guess what we're trying to find out is what's more
troublesome and/or surprising:
1. having to set the port explicitly (to #f?) when you want to change the
scheme and its port
2. having to set the port
Hi,
If anyone on this mailinglist has strong opinions either way, please let
yourselves be heard: now's the time to speak up.
If there was a vote then I'd vote to preserve an explicit port setting but
dynamically choose the correct one, based on scheme, when port is #f.
I don't think we
On Friday, 16 May 2014 14:28:51 BST, Andy Bennett wrote:
Hi,
If anyone on this mailinglist has strong opinions either way, please let
yourselves be heard: now's the time to speak up.
The existing behaviour seems reasonable as it only does it when setting
scheme, not when setting other parts
Hi guys,
I have come across som a bug or unintuitive behaviour in uri-common. The
port parameter is reset on update-uri. uri-generic works like expected:
csi -R uri-generic
#;1 (update-uri (make-uri port: 100) scheme: 'http)
#(URI scheme=http authority=#(URIAuth host=#f port=100) path=()
On Tue, May 13, 2014 at 01:38:16PM +0200, Kristian Lein-Mathisen wrote:
Hi guys,
I have come across som a bug or unintuitive behaviour in uri-common. The
port parameter is reset on update-uri. uri-generic works like expected:
csi -R uri-generic
#;1 (update-uri (make-uri port: 100) scheme:
Hmmm ... The scheme is changed, like you say, but the port is too, from 100
to #f, which is what I find surprising.
I cannot seem to find a way to update the uri without loosing the port.
What am doing wrong here?
K.
On May 13, 2014 1:48 PM, Peter Bex peter@xs4all.nl wrote:
On Tue, May 13,
On Tue, May 13, 2014 at 11:25:23PM +0200, Kristian Lein-Mathisen wrote:
Hmmm ... The scheme is changed, like you say, but the port is too, from 100
to #f, which is what I find surprising.
I cannot seem to find a way to update the uri without loosing the port.
What am doing wrong here?
Try
A, of course, now I understand what you were trying to tell me previously.
That makes sense. Thanks for clarifying, Peter.
In my particular use-case, I am changing to a custom scheme and this port
clear on scheme change feature made me scratch my head for a while (but
that happens quite often, so
On Tue, May 13, 2014 at 11:37:53PM +0200, Kristian Lein-Mathisen wrote:
A, of course, now I understand what you were trying to tell me previously.
That makes sense. Thanks for clarifying, Peter.
Glad my ramblings were helpful!
In my particular use-case, I am changing to a custom scheme and
Peter Bex scripsit:
If anyone on this mailinglist has strong opinions either way, please let
yourselves be heard: now's the time to speak up.
I think the existing behavior is correct, because scheme and port are
tied together.
--
John Cowan http://www.ccil.org/~cowan
19 matches
Mail list logo