[Ur] Mandatory nginx conf: merge_slashes off

[Simon Van Casteren]

It doesn't happen often of course, since you rarely use unit in a page or
RPC function. How I ran into it was actually via the now fixed bug
https://github.com/urweb/urweb/issues/117, I made some ADT's that got
around that bug by declaring all constructors to have at least one
parameter, unit if nothing else. That came back to bite me now...

A page with this signature:

val page: unit -> string -> transaction page

Would be affected by the issue I described. This obviously won't happen
much outside of you making a mistake (for example because first the
function took just a unit, then you added the string parameter), but
because it doesn't happen often and it's actually nginx making the
"mistake", I still thought it could help someone out in the future!

Simon

On Fri, 25 Jan 2019 at 13:57, Adam Chlipala <adamc at csail.mit.edu> wrote:

> Thanks for sharing that wisdom!  Somehow I remember making a special
> effort to encode empty strings with underscores, precisely to avoid this
> problem (though it was appearing in Apache, if I recall correctly).  Can
> you point us to an example where it arises, in a URL that an Ur/Web app
> generates itself?
>
> On 1/25/19 5:13 AM, Simon Van Casteren wrote:
>
> Hi,
>
> I just ran into an awful problem combining urweb with nginx. By default,
> nginx by default merges double slashes in urls, eg:
> http://www.bla.com//users becomes http//www.bla.com/users. This can be a
> problem for UrWeb applications since a double slash is actually how urweb
> encodes the unit or () value.
>
> The solution is to use the option: "merge_slashes off".
>
> It's not a bug in either application so I didnt want me make an issue for
> it, but this could be useful info for other people running Ur/Web programs
> behind nginx...
>
> Simon
>
> _______________________________________________
> Ur mailing list
> Ur at impredicative.com
> http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.impredicative.com/pipermail/ur/attachments/20190125/5eccc0af/attachment.html>