The new net/http-client library addresses the problems in this thread.
Jay
On Sat, Jul 13, 2013 at 8:07 PM, Eli Barzilay wrote:
> Regardless of specs, it's useful to be able to talk to servers even
> when they're misbehaving. A nice possible way to deal with this is to
> expose some more primit
Regardless of specs, it's useful to be able to talk to servers even
when they're misbehaving. A nice possible way to deal with this is to
expose some more primitive layer using raw strings.
Two days ago, Jay McCarthy wrote:
> This debate is bigger than you and me, but I don't see a spec
> here.
I'd agree that a string and/or bytes value supplied as a query
component would be the best solution. Let us shoot ourselves in our
feet!
In terms of a comprehensive url api, I think the argument would be
that application/x-www-form-urlencoded query strings are the most
common use case, but certainl
Even and I spoke offline, and although I don't have all the details (and
something sounds odd), it currently sounds like the core problem here is
that some server program (perhaps not stock Shibboleth itself) is
unusually non-compliant in its handling of URLs.[*]
Although the problem here does
Evan Donahue wrote at 07/11/2013 04:04 PM:
I do think, however, that what strikes me as an increasing
preponderance of 'creative' url interpretation in the age of SAAS may
make a case for greater control over the path/query/fragment portion
of the url, whether or not that falls under the offici
For what it's worth, the url in the query section is used for redirection
after shibboleth authentication at a large institution. I don't anticipate
that changing. I do think, however, that what strikes me as an increasing
preponderance of 'creative' url interpretation in the age of SAAS may make
a
(excuse me for butting in here...)
I'd add my agreement that the referenced spec rfc 3986 supports Evan's
usage with the definition being very clear on this point. The ? should
not be encoded. On the other hand the preceding rfc 1738 (3.3)
specifies that the ? is a reserved character in the "searc
First, I think in this particular case the RFCs agree with Evan here.
In particular, see section 3.4 of RFC 3896:
http://tools.ietf.org/html/rfc3986#section-3.4 which defines query
strings as containing a sequence of either 'pchar', "/" or "?", where
'pchar' includes ":", ascii alphanumeric charact
This debate is bigger than you and me, but I don't see a spec here. I
see a weird pseudo-code parsing algorithm with no specification. In
any case, the net/url module implements the RFCs. If those aren't what
you want, then it needs to be changed or a new module needs to be
implemented. Given the b
I'm not sure which spec you're looking at from there, but the URL spec
that I linked to is the most current work on precisely specifying
URLs.
On Thu, Jul 11, 2013 at 2:14 PM, Jay McCarthy wrote:
> I'm looking at the spec: http://www.w3.org/Addressing/
>
> On Thu, Jul 11, 2013 at 11:59 AM, Sam To
I'm looking at the spec: http://www.w3.org/Addressing/
On Thu, Jul 11, 2013 at 11:59 AM, Sam Tobin-Hochstadt wrote:
> On Thu, Jul 11, 2013 at 1:46 PM, Jay McCarthy wrote:
>> On Wed, Jul 10, 2013 at 5:27 PM, Evan Donahue wrote:
>>> Hello, I am trying to use the racket networking libraries for a
On Thu, Jul 11, 2013 at 1:46 PM, Jay McCarthy wrote:
> On Wed, Jul 10, 2013 at 5:27 PM, Evan Donahue wrote:
>> Hello, I am trying to use the racket networking libraries for a basic set of
>> get and post requests. I need to send a url of the form:
>>
>> http://foo.com/?url=http://bar.com?baz=1000
On Wed, Jul 10, 2013 at 5:27 PM, Evan Donahue wrote:
> Hello, I am trying to use the racket networking libraries for a basic set of
> get and post requests. I need to send a url of the form:
>
> http://foo.com/?url=http://bar.com?baz=1000 (NOT form encoded)
As far as I can tell from URL specs, th
13 matches
Mail list logo
