As title really... as we all know WebSharper still has that epic bug where the JQuery URL is hardcoded to http:// which breaks hosting on HTTPS. Unfortunately web.config is not suitable for us and we'd like to override the URL programmatically during startup. How can this be achieved? Thanks!

  • loic.denuziere

    So, first of all -- we will probably fix the jQuery URL to point to https by default very soon (and check that all our extensions that point to a CDN do the same).

    In the meantime, or if you still want to change the URL of a resource, you can use something like the following:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    
    module Context =
    
        let WithSettings (settings: seq<string * string>) (ctx: Context<'T>) : Context<'T> =
            let settings = dict settings
            let getSetting k =
                match settings.TryGetValue(k) with
                | true, x -> Some x
                | false, _ -> ctx.ResourceContext.GetSetting k
            { ctx with ResourceContext = { ctx.ResourceContext with GetSetting = getSetting } }
    
    module Sitelet =
    
        let MapContext (f: Context<'T> -> Context<'T>) (sitelet: Sitelet<'T>) : Sitelet<'T> =
            { sitelet with
                Controller = { Handle = fun action ->
                    Content.CustomContentAsync <| fun ctx ->
                        Content.ToResponse (sitelet.Controller.Handle action) (f ctx)
                }
            }
    
        let WithSettings (settings: seq<string * string>) (sitelet: Sitelet<'T>) : Sitelet<'T> =
            MapContext (Context.WithSettings settings) sitelet
    
    // Example use:
    [<Website>]
    let Main =
        Application.MultiPage (fun ctx endpoint -> (* your application... *))
        |> Sitelet.WithSettings [
            "WebSharper.JQuery.Resources.JQuery", "https://code.jquery.com/jquery-1.11.0.min.js"
        ]

    I'll discuss with the team whether it would also be a good idea to add the above functions to the library.

    • nbevans

      Thank you this looks very useful and should cleanly resolve the problem for now.

      Just to note when you do fix the bug, please use "//blah/blah/somefile.ext". Which is to say, do not specify http: nor https: in front. This will ensure the browser uses the same scheme as the sitelet was loaded through. Which ensures the best possible compatibility.

      • loic.denuziere

        The inconvenient of "//url" without protocol is that it doesn't work when testing a single-page application from the filesystem (with "file://" protocol). In what situation would there be an incompatibility for an http site loading an https script?