[Ur] Unsafe GET and slow message passing

[Adam Chlipala]

On 08/29/2015 01:16 AM, Ziv Scully wrote:
> (1) Say that [handler : unit -> transaction page] makes a write to a 
> database. Normally we can't just use [handler] as a link without a 
> [safeGet] in the relevant .urp file. However without exposing 
> [handler] in the .urs file or adding the [safeGet], we can do 
> [<form><submit={handler}></form>]. This makes [handler] accessible by 
> simply typing in a URL, even if it has destructive effects, because 
> the form handler expects no fields. There's a simple workaround for 
> now: add a [<hidden{#Dummy}/>] to the form (and change the type of 
> [handler] accordingly).

This is the easier of the two to respond to. :)

The behavior you report is expected.  The general Ur/Web model is:
(1) The language and implementation help you enforce important 
invariants, for security or otherwise.
(2) However, the model is still that any page handler could be called 
with any arguments (and any applicable HTTP verb!) at any time.  The 
"side effects must use PUT" rule is only enforced for user interaction 
sequences that follow the normal control flow of your application, with 
no "protection" against wise guys who craft their own URLs.  IMO, you 
should make sure that a user calling a URL "out of order" may be able to 
break his own state, in a relatively benign way, but not break anyone 
else's state.

> (2) Sometimes doing "many" (order of 6) channel operations slows down 
> the server considerably, causing all requests to stall for a bit. The 
> stall isn't permanent, but often after the stall resolves, some small 
> subset of the messages don't make it to their recipients. The clients 
> who missed messages might still receive future messages but will never 
> receive the ones they missed. I found that something similar occurs 
> with the official Chat demo (try joining the same channel in ~8 tabs 
> in quick succession), so I don't think the issue is specific to my 
> app. Has anyone run into this before? I messed with the .urp file a 
> little bit but nothing helped.

Hm, I never noticed that before!  It may be a concurrency bug in the 
runtime system.  I'll look into it further.