<div dir="ltr">A new kind of dict seems like it would be able to deal with much of this. For example, you could have a 'get' operation that would deal with the multiple headers situation in a way that is likely to be what was intended (whether that's an error or a 'get the last one' or some other operation) and a get-multiple that would return the list (and have a longer name so people wouldn't glom to it), similarly it could deal with lookups without canonicalizing case ahead of time. You could have some kind of extensible mechanism for dealing with parsing the right-hand sides of the table and pre-populate it with the ones that are commonly cared about. Because of the generics, this woudl "just work" when someone sticks it into a for loop, as long as they are just doing something easy.<div>
<br></div><div>Robby</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Sep 17, 2013 at 8:51 AM, Jay McCarthy <span dir="ltr"><<a href="mailto:jay.mccarthy@gmail.com" target="_blank">jay.mccarthy@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think it's an obvious request, but a character flaw of mine is not<br>
doing things unless they can be done really good. In this case, I see<br>
a hash table as a "parse" of the headers. It's not obvious to me how<br>
to parse them. For example...<br>
<br>
- The same header can appear many times, so (Key -> Value) is<br>
incorrect, unless you overwrite one. It would be better to have (Key<br>
-> (Listof Value)) but that feels really ugly since most of the time<br>
there will just be one<br>
- The spec doesn't mandate case sensitivity on headers, so I would<br>
need to canonicalize "ACCept-ENCodiNG" to something else. Maybe<br>
'Accept-Encoding?<br>
- The value of many headers is not really a string. For instance,<br>
Content-Length is a number, Cache-Control is an association list,<br>
Content-Disposition is complicated, etc. I feel like it is<br>
disingenuous to only partial parse.<br>
- Dealing with all this may be wasted effort for most requests that<br>
just care about the body<br>
<br>
For these reasons, I think http-client should just return the list of<br>
bytes. I think it would be nice to have another function that parses<br>
that so clients could optionally call it if it is important. That can<br>
be part of http-client.<br>
<br>
Jay<br>
<br>
<br>
<br>
On Tue, Sep 17, 2013 at 3:41 AM, adam moore <<a href="mailto:nerdfunk@gmail.com">nerdfunk@gmail.com</a>> wrote:<br>
> Hi Jay,<br>
><br>
> Just looking over the new http client code - looking very nice, and<br>
> much better than my current slapped together parsing of<br>
> get-impure-port.<br>
><br>
> I was wondering if it might be better to pass back the headers as<br>
> something easier to look up against, for example as a hash table? Or<br>
> perhaps, provide an option to do so. I think it's a pretty common use<br>
> case to provide for.<br>
><br>
> Thanks again,<br>
> Adam<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
--<br>
Jay McCarthy <<a href="mailto:jay@cs.byu.edu">jay@cs.byu.edu</a>><br>
Assistant Professor / Brigham Young University<br>
<a href="http://faculty.cs.byu.edu/~jay" target="_blank">http://faculty.cs.byu.edu/~jay</a><br>
<br>
"The glory of God is Intelligence" - D&C 93<br>
____________________<br>
  Racket Users list:<br>
  <a href="http://lists.racket-lang.org/users" target="_blank">http://lists.racket-lang.org/users</a><br>
</div></div></blockquote></div><br></div>