Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

When used to host static websites cache-timeout should not be 48 weeks #1234

Closed
Luzifer opened this issue May 16, 2015 · 8 comments · Fixed by #1272
Closed

When used to host static websites cache-timeout should not be 48 weeks #1234

Luzifer opened this issue May 16, 2015 · 8 comments · Fixed by #1272

Comments

@Luzifer
Copy link
Member

Luzifer commented May 16, 2015

As a website owner hosting his website in IPFS I want to be able to make updates to that page.

Scenarios

  1. I use http://some.gate.way/ipfs/QmczrnBpAgnhCo87rtZ8VbLfGU5v8g7cKr7Ef2fKRvYniA/index.html to host the website
    • It's okay the page is cached for the next 48 weeks, when I'm doing updates I will change the hash in links
  2. I use http://myweb.site/ with a dnslink TXT DNS entry
    • I will not change the URL itself but the hash in the DNS. Though the URL http://myweb.site/ is cached for the next 48 weeks and I'm not able to make changes because I'm not able to clear the visitors DNS caches

Solution

Apply the solution used for /ipns/... hashs also to requests coming from a dnslink entry

Steps to check

# curl -s -i -H 'Host: swagger.luzifer.io' http://localhost:8080/ | head -n20
HTTP/1.1 200 OK
Accept-Ranges: bytes
Cache-Control: public, max-age=29030400
Content-Length: 3921
Content-Type: text/html; charset=utf-8
Etag: index.html
Last-Modified: Thu, 01 Jan 1970 00:00:01 GMT
Suborigin: QmczrnBpAgnhCo87rtZ8VbLfGU5v8g7cKr7Ef2fKRvYniA
X-Ipfs-Path: /ipfs/QmczrnBpAgnhCo87rtZ8VbLfGU5v8g7cKr7Ef2fKRvYniA/index.html/
Date: Sat, 16 May 2015 11:03:43 GMT

<!DOCTYPE html>
<html>
<head>
  <title>Swagger UI</title>
@Luzifer Luzifer mentioned this issue May 16, 2015
Merged
@Luzifer
Copy link
Member Author

Luzifer commented May 16, 2015

Suggested solution in #1208:

diff --git a/core/corehttp/ipns_hostname.go b/core/corehttp/ipns_hostname.go
index 7361001..0da667c 100644
--- a/core/corehttp/ipns_hostname.go
+++ b/core/corehttp/ipns_hostname.go
@@ -19,8 +19,8 @@ func IPNSHostnameOption() ServeOption {
                        defer cancel()

                        host := strings.SplitN(r.Host, ":", 2)[0]
-                       if p, err := n.Namesys.Resolve(ctx, host); err == nil {
-                               r.URL.Path = "/ipfs/" + p.String() + r.URL.Path
+                       if _, err := n.Namesys.Resolve(ctx, host); err == nil {
+                               r.URL.Path = "/ipns/" + host + r.URL.Path
                        }
                        childMux.ServeHTTP(w, r)
                })

For /ipns/ there is already special Cache-Control handling and as the hostname feature basically belongs to IPNS this would be the most straight forward solution.

@jbenet
Copy link
Member

jbenet commented May 16, 2015

Agreed. We should keep in mind what the request is and use that to determine whether or not to cache. 

Actually, ideally we would do 302 redirects (not cached) to proper /ipfs/ path (immutable, cached forever).

—
Sent from Mailbox

On Sat, May 16, 2015 at 2:57 PM, Knut Ahlers [email protected]
wrote:

Suggested solution in #1208:

diff --git a/core/corehttp/ipns_hostname.go b/core/corehttp/ipns_hostname.go
index 7361001..0da667c 100644
--- a/core/corehttp/ipns_hostname.go
+++ b/core/corehttp/ipns_hostname.go
@@ -19,8 +19,8 @@ func IPNSHostnameOption() ServeOption {
                        defer cancel()
                        host := strings.SplitN(r.Host, ":", 2)[0]
-                       if p, err := n.Namesys.Resolve(ctx, host); err == nil {
-                               r.URL.Path = "/ipfs/" + p.String() + r.URL.Path
+                       if _, err := n.Namesys.Resolve(ctx, host); err == nil {
+                               r.URL.Path = "/ipns/" + host + r.URL.Path
                        }
                        childMux.ServeHTTP(w, r)
                })

For /ipns/ there is already special Cache-Control handling and as the hostname feature basically belongs to IPNS this would be the most straight forward solution.

Reply to this email directly or view it on GitHub:
#1234 (comment)

@jbenet
Copy link
Member

jbenet commented May 16, 2015

Actually 307

—
Sent from Mailbox

On Sat, May 16, 2015 at 2:57 PM, Knut Ahlers [email protected]
wrote:

Suggested solution in #1208:

diff --git a/core/corehttp/ipns_hostname.go b/core/corehttp/ipns_hostname.go
index 7361001..0da667c 100644
--- a/core/corehttp/ipns_hostname.go
+++ b/core/corehttp/ipns_hostname.go
@@ -19,8 +19,8 @@ func IPNSHostnameOption() ServeOption {
                        defer cancel()
                        host := strings.SplitN(r.Host, ":", 2)[0]
-                       if p, err := n.Namesys.Resolve(ctx, host); err == nil {
-                               r.URL.Path = "/ipfs/" + p.String() + r.URL.Path
+                       if _, err := n.Namesys.Resolve(ctx, host); err == nil {
+                               r.URL.Path = "/ipns/" + host + r.URL.Path
                        }
                        childMux.ServeHTTP(w, r)
                })

For /ipns/ there is already special Cache-Control handling and as the hostname feature basically belongs to IPNS this would be the most straight forward solution.

Reply to this email directly or view it on GitHub:
#1234 (comment)

@Luzifer
Copy link
Member Author

Luzifer commented May 16, 2015

Actually, ideally we would do 302 redirects (not cached) to proper /ipfs/ path (immutable, cached forever).

I don't think so. That would be really ugly and at least prevent me 100% from using IPFS for static websites. Imagine this:

  • You visit swagger.luzifer.io to see the website hosted there
  • The URL changes to http://[whatever]/ipfs/QmczrnBpAgnhCo87rtZ8VbLfGU5v8g7cKr7Ef2fKRvYniA/ instead. As owner of the site I would not want this. This also breaks everything you can sum using the term "SEO" as the domain looses all relevance and is a redirect-grave…

In my special case:

  • You visit http://swagger.luzifer.io/?url=[hash here]
  • You get redirected to http://[whatever]/ipfs/QmczrnBpAgnhCo87rtZ8VbLfGU5v8g7cKr7Ef2fKRvYniA/
  • The parameter is lost, the vanity URL is lost, everything breaks…

(The change is not for http://[gateway]/ipns/[hash] links but for real domains using the dnslink feature.)

@jbenet
Copy link
Member

jbenet commented May 16, 2015

@Luzifer Mmm yeah one doesn't see the output of the redirects for assets, but does for the main page. Wait, we should test whether 307 displays the original URL. Since it is "temporary only" it may display the original and hide the redirect.

@Luzifer
Copy link
Member Author

Luzifer commented May 16, 2015

Nah. The redirect is shown in the browser as expected. If you wanna test yourself:

package main

import (
    "fmt"
    "net/http"

    "github.com/gorilla/mux"
)

func main() {
    r := mux.NewRouter()

    r.HandleFunc("/patha", func(res http.ResponseWriter, r *http.Request) {
        http.Redirect(res, r, "/pathb", 307)
    })

    r.HandleFunc("/pathb", func(res http.ResponseWriter, r *http.Request) {
        fmt.Fprintf(res, "ohai")
    })

    http.Handle("/", r)
    http.ListenAndServe(":4000", nil)
}

@jbenet
Copy link
Member

jbenet commented May 17, 2015

@Luzifer bummer.

@Luzifer
Copy link
Member Author

Luzifer commented May 21, 2015

Blocked by #1267

@Luzifer Luzifer mentioned this issue May 21, 2015
Merged
rht pushed a commit to rht/go-ipfs that referenced this issue May 26, 2015
@Luzifer
Fix: dnslink domain resolving was broken; Add: no caching for those
0895966 
fixes ipfs#1234
fixes ipfs#1267
@recmo recmo mentioned this issue Apr 13, 2017
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Fix: dnslink domain resolving was broken; Add: no caching for those
2 participants
@Luzifer @jbenet