[racket-dev] Documentation lacuna?
Greetings. In the web server, the documentation for RESPONSE and, by implication, RESPONSE/FULL does not explain how to avoid including a message-body in the response, as is required for 1xx, 204, 304 statuses (and those alone). By experiment, giving RESPONSE/FULL a 'body' argument of # produces the right effect, but: (a) it would be reassuring if this case was mentioned in the documentation; (b) this still produces a content-length:0 header. A problem is that without reassurance in (a), giving an empty 'body' feels slightly like a hack. It might be that allowing an 'output' or 'body'' argument of #f would communicate the intent more clearly. Regarding (b), RFC 2616 Sect. 4.4 doesn't say that a Content-Length header is invalid in one of these responses, but it does imply (point 1 in that section) that the Content-Length header should be ignored in that case. This means that it's slightly unsightly (no more) that the header appears in a RESPONSE/FULL response. So, suggestion: either support an 'output' (for RESPONSE) or 'body' (for RESPONSE/FULL) argument of #f, which is documented to be appropriate only for certain statuses, and which suppresses the content-length; or document that giving a 'body' of # is indeed the approved way of giving a no-body response for these statuses, and that the content-length is generated but redundant. Best wishes, Norman -- Norman Gray : http://nxg.me.uk SUPA School of Physics and Astronomy, University of Glasgow, UK _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Documentation lacuna?
Sorry, an addendum... On 2013 Jan 21, at 12:23, Norman Gray nor...@astro.gla.ac.uk wrote: In the web server, the documentation for RESPONSE and, by implication, RESPONSE/FULL does not explain how to avoid including a message-body in the response, as is required for 1xx, 204, 304 statuses (and those alone). By experiment, giving RESPONSE/FULL a 'body' argument of # produces the right effect, but: (a) it would be reassuring if this case was mentioned in the documentation; (b) this still produces a content-length:0 header. The other thing (ahem...) is that without such an explanation, it's not clear what to put as the MIME type. Since there's no content, it's tempting to conclude that the 'mime' argument is ignored. If, however, one gives this argument as # (on the grounds that it doesn't matter what it is), this is faithfully send down the wire as a Content-Type: header, which is invalid. Giving 'mime' as #f (which is allowed in the contract of RESPONSE but not otherwise documented) _does_ suppress the content-type header, even though the documentation for RESPONSE states that the server will automatically add a Content-Type header if one is not present. That is, one can produce the correct behaviour here, even though the documentation seems to suggest that no-body responses will be problematic. Best wishes, Norman -- Norman Gray : http://nxg.me.uk SUPA School of Physics and Astronomy, University of Glasgow, UK _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Documentation lacuna?
Jay, hello. On 2013 Jan 21, at 16:12, Jay McCarthy jay.mccar...@gmail.com wrote: I don't understand your concern. The response structure, which is the only actual structure (everything else is an interface on it)... a) Allows #f as the mime type ...but the documentation doesn't say what #f means here. Does it mean 'dunno, you work it out', or 'there is no content', or 'use some default'? In fact it means I promise there isn't any output, so so I don't have to tell you a MIME type, but that can only be discovered from experiment or inspecting the source. b) Has you provide an 'output' function that does the output. If you don't want there to be any output, then don't write any: (response 304 #304 (current-seconds) #f empty void) When I read the documentation for RESPONSE, I thought 'oh dear, it doesn't know about no-content responses', because it reads as if it assumes (and implements) that every HTTP response has a message-body. Reading output produces the body suggests that there's always supposed to be a body, especially because it seems to suggest that it _always_ produces a Content-Type header. I don't think this is an outrageously wrong reading of the paragraph. So, what exactly is it that you want, if not what is already provided? How about a second paragraph after An HTTP response... which reads: Certain HTTP responses (with status 1xx, 204 and 304) have no content. These are correctly generated with a response structure which has #f for 'mime' and 'void' for 'output'. Such responses have no message-body, and no content-length or content-type headers. An alternative interface would be to have the response structure let output be (or/c false/c (- output-port? void?)), and indicate that output:#f produces no output, ignores any MIME type and produces no Content-Type header. That's potentially clearer (easier to guess the effect of) in the no-output case. (response 304 #Not Modified (current-seconds) #IGNORED (list (make-header #Location #http://racket-lang.org/download;)) #f) Finally: Re-reading what I first wrote, I suspect I was becoming slightly fixated on response/full over response, which meant I was a good bit less clear than I should have been. Sorry about that. Best wishes, Norman -- Norman Gray : http://nxg.me.uk SUPA School of Physics and Astronomy, University of Glasgow, UK _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Formlets and POST
Greetings. Web-server formlets currently send their form input back to the server via an HTTP GET request. They should probably generate a form which uses HTTP POST instead. There are two problems with using GET for this. 1. If there's any sensitive information in the form, such as a password, then it's very obviously exposed in the URL and stored in logs, which wouldn't be the case if the form contents are in the HTTP request body instead. The latter would provide at least a little bit of obscurity, rather than serious security. This is of course not a great way to do authentication (to say the least), but if one trusts the network or one is talking to localhost, then it's good enough for some applications. The problem isn't just confined to passwords, obviously. 2. HTTP defines GET to be side-effect free, and cacheable. Therefore if there's an intermediary server between the client and the server, and it sees a GET request being made, it is (a) permitted to send a cached version if the URL is one it has seen before, and (b) permitted to make the GET request to the origin server multiple times (for example if there is or appears to be a failure), and send only one response to the client. Either of these might mess up the form-mediated client-server interaction, and there's nothing anyone can do about it. This is probably more of a theoretical problem than a common practical one. POST is not defined to be side-effect free, and is not automatically cacheable. Of course (again), the point of continuation-based forms is that they're functional, just like GET, but many people implement services using GET forms which are intended to have side-effects. Simply defining (and using) a send/formlets/post which is identical to send/formlets but with a [method POST] added, seems to work fine, because formlet-process uses request-bindings/raw, which handles both GET and POST requests. Therefore, I think that should probably be the default. Best wishes, Norman -- Norman Gray : http://nxg.me.uk SUPA School of Physics and Astronomy, University of Glasgow, UK _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] new logo
Greetings. On 2012 Feb 14, at 20:37, Neil Toronto wrote: Here's the deal, though. This one, even just the lambda r. in a circle, is pushing complexity. We've been approaching logo design too much like language design, trying to cram as much semantic content as possible into a small space or into the fewest shapes. A logo exists primarily to make a good impression on outsiders. Filling it with too much meaning works actively against this. That's very true. Also, there's quite a lot of visually arresting features in that banner -- the lambda in a circle, the artfully mismatched brackets, the shape of the letters, the margins on the letters, the colours -- each one of which would be distinctive by itself. Here's another banner-shaped suggestion: http://nxg.me.uk/temp/lambdas.html. Perhaps I just like white space, but this seems to say quite a lot, and be distinctive, without looking busy (the 'r' is different from the previous suggestions, being Optima rather than Gill Sans). Scheme is all about letting a little say a lot, and so it seems to me that really pared-back minimalism is a great look for Racket. Logos should be designed not by piling feature on top of feature, but by removing Best wishes, Norman -- Norman Gray : http://nxg.me.uk SUPA School of Physics and Astronomy, University of Glasgow, UK _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] new logo
Greetings. I've no real standing here -- this is an observation from the sidelines On 2012 Feb 13, at 06:05, SF wrote: Another way to combine lambda and capital R: http://i.imgur.com/PuGTE.png Combining the lambda and the R in this way looks like a very good idea to me. I can see the point to the original 'r' logo -- it picks up the previous PLT colours, it looks nicely informal (though that particular example perhaps went a little too far, and could look childish), and of course it picks up the 'r' of Racket. I'm also one of those who thinks it'd be a shame to lose the lambdas, and I think that SF's suggestion here marries several of these desiderata. With that in mind, I'll suggest a variant of it (born analogue, I'm afraid, rather than as pixels) http://nxg.me.uk/temp/lambda-r.png The first three seem to be tending towards the florid, but some more rhythmic version of the other three -- variants of 'λr.' -- might be worth closer examination. I'm aware the last one of the six is starting to look more like lambda-tau. Best wishes, Norman -- Norman Gray : http://nxg.me.uk SUPA School of Physics and Astronomy, University of Glasgow, UK _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] new logo
On 2012 Feb 13, at 14:54, Philippe Meunier wrote: For some reason it slightly reminds me of a symbol for some religious cult or political party, which might or might not be a good thing. Whoa! Doesn't it just! Another thing that occurred to me, on the same model as before, is to go for an almost completely typographical logo. At http://nxg.me.uk/temp/lambda-r5.pdf is a possibility. It's just '\r.', really, but with the lambda in a cursive font, the 'r.' in a modern one (Gill Sans), and some pretty aggressive tracking to make it into a unit. That doesn't have the shinies of other suggestions, but it's obviously very adaptable and (to my aesthetic at least) matches the chiselled restraint of a Scheme. I think that's exhausted my visual creativity for the day, so I'll shut up now All the best, Norman -- Norman Gray : http://nxg.me.uk SUPA School of Physics and Astronomy, University of Glasgow, UK _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] new logo
Greetings. On 2012 Feb 13, at 17:03, Matthias Felleisen wrote: I do actually like the combination of lambda and r, though I am sure the color scheme could benefit from some variation. Less might be more, but http://nxg.me.uk/temp/lambda-r6.pdf shows an adjustment. The blue is a bit too light, the red a bit too pink, and the text could perhaps be a shade bigger, but the shape is not, I think, unpleasing. All the best, Norman On Feb 13, 2012, at 10:25 AM, Norman Gray wrote: On 2012 Feb 13, at 14:54, Philippe Meunier wrote: For some reason it slightly reminds me of a symbol for some religious cult or political party, which might or might not be a good thing. Whoa! Doesn't it just! Another thing that occurred to me, on the same model as before, is to go for an almost completely typographical logo. At http://nxg.me.uk/temp/lambda-r5.pdf is a possibility. It's just '\r.', really, but with the lambda in a cursive font, the 'r.' in a modern one (Gill Sans), and some pretty aggressive tracking to make it into a unit. That doesn't have the shinies of other suggestions, but it's obviously very adaptable and (to my aesthetic at least) matches the chiselled restraint of a Scheme. I think that's exhausted my visual creativity for the day, so I'll shut up now All the best, Norman -- Norman Gray : http://nxg.me.uk SUPA School of Physics and Astronomy, University of Glasgow, UK _ Racket Developers list: http://lists.racket-lang.org/dev -- Norman Gray : http://nxg.me.uk SUPA School of Physics and Astronomy, University of Glasgow, UK _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Racket home page proposal
Greetings. On 2011 Dec 20, at 05:34, Asumu Takikawa wrote: Currently, the Racket home page is really nice, but it leaves a significant amount of vertical space unused that could be used to communicate information. ...or which could be used, as now, to project authority and decisiveness. The white space below the text currently on the Racket page says this is all that has to be said at this point; follow the links above for more information. That makes me at least pay more attention to it. If there's more text on the page, as in the sample page, I read less of it, and I don't imagine I'm alone in that. I can feel my eyes gliding over the page, trying to find some way of parsing it. I alight on the 'Download Racket' link, and on the 'About', 'Download', 'Documentation', ... headlines, and they end up being the only things I see at all. Best wishes, Norman -- Norman Gray : http://nxg.me.uk SUPA School of Physics and Astronomy, University of Glasgow, UK _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Missing pregexp syntax in Racket
On 2011 Nov 29, at 18:14, Neil Van Dyke wrote: 1. Everyone should acknowledge the JWZ quote, Some people, when confronted with a problem, think 'I know, I'll use regular expressions.' Now they have two problems. Regular expressions are Perl's hammer that makes most problems look like a nail. What Neil said! 2. Before someone spends too much time putting the finishing touches on old Unix/Perl regular expression syntax, they might want to look at Olin Shivers's SREs. Sexp-based regular expression syntax can be a big readability win when your regexps get complicated. http://www.ccs.neu.edu/home/shivers/citations.html#sre What Neil said _and_ what Shivers said! Implementing Shivers-style SREs would be a much bigger win than any alternate pregexp syntax with differently funky backslash rules from everything else. Norman -- Norman Gray : http://nxg.me.uk SUPA School of Physics and Astronomy, University of Glasgow, UK _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] PLaneT and proxies
Robby, hello. Back around 2010 June 20, there was a discussion about PLaneT and proxies. It ended with: On 2010 Jun 21, at 09:43, Norman Gray wrote: Oh-- Eli pointed out something offlist: did you try starting up drracket, setting its proxy preferences and then trying to install something from planet? I didn't try that -- it didn't occur to me, I'm afraid. I imagine that would work fine (if I need to do this again, and it doesn't work, I'll shout). I just have now needed to do this again, and it it works fine, once DrRacket has its proxy settings correct. Best wishes, Norman -- Norman Gray : http://nxg.me.uk _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
