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.

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

Issues viewing safe://dweb with SB 0.15.2 #1061

Closed
theWebalyst opened this issue Oct 24, 2019 · 9 comments
Projects

Comments

@theWebalyst
Copy link

@theWebalyst theWebalyst commented Oct 24, 2019

I built 0.15.2 to try it out with safe://dweb before I announce a new post and see quite a few issues. There are now three versions of safe://dweb on the shared vault so it might be a good test for bugs and/or to highlight things that need to be done differently for websites to work on SAFE.

Ideally a versioned/pWeb static website like this would 'just work' but I'm not sure if that will be possible, so this is potentially a place to highlight things that work on the web but not SAFE, and how to fix them.

The kinds of things I'm seeing are shown below (using the shared vault):

Default (latest version)

  • load safe://dweb: page displays but styles are not loaded
  • click on 'Blog' at top of page: 'index.html' is not loaded so SB shows file listing
  • click on 'index.html': page displays correctly and then disappears, and then shows 404
  • reload the page: same happens again
  • click on 'Blog' at top of page: page displays correctly
  • click on 'Why Solid on SAFE?': the post displays correctly
  • page navigation links (Home, About, Blog) now seem to work and pages display correctly
  • click 'Blog' > 'Why Solid on SAFE?' > 'Back to Articles' (at bottom of page): page doesn't load index.html and instead displays directory listing

This is before trying to step back through versions.

Try versioning

Clean tab:

  • visit 'safe://dweb': styles don't load (as above)
  • click < for previous version: address bar shows ?v=1 and the page loads properly (ie including styles)
  • click < again: address bar updates to ?v=0 and page renders index.html as text (not HTML).

That's enough for now!

@theWebalyst

This comment has been minimized.

Copy link
Author

@theWebalyst theWebalyst commented Oct 24, 2019

Trying out safe://solid-filemanager which worked fine with 0.15.1, I can't get any page to load as HTML. Typing any of the following into the address bar all show the HTML of index.html as text rather than rendering the HTML:

solid-filemanager
safe://solid-filemanager/index.html
safe://solid-filemanager/index.html?v=2
safe://solid-filemanager/index.html?v=1
safe://solid-filemanager/index.html?v=0
safe://solid-filemanager/?v=2

Same when moving back and forward through versions with < and >

Note:

  • safe://dweb is built using React-static
  • safe://solid-filemanager is built using React
@theWebalyst

This comment has been minimized.

Copy link
Author

@theWebalyst theWebalyst commented Oct 29, 2019

With the official release I retried the dweb test in the OP and confirm that these issues are present in the just released SB 0.15.2.

@joshuef

This comment has been minimized.

Copy link
Collaborator

@joshuef joshuef commented Nov 5, 2019

Totally didn't catch this issue, apologies. Digging in now

@joshuef

This comment has been minimized.

Copy link
Collaborator

@joshuef joshuef commented Nov 5, 2019

What we really need in browser is a script for uploading test pages to recreate such scenarios and then automated testing of our resolution etc.

@joshuef joshuef added this to To do in pWeb1 via automation Nov 5, 2019
@joshuef

This comment has been minimized.

Copy link
Collaborator

@joshuef joshuef commented Nov 5, 2019

@theWebalyst can you check the HTML files and the version of the JS/CSS they are requesting.

It looks like they're after versions that don't exist on the container: (which you can see: safe://dweb/?container=true), which would make sense that they're not loading.

@joshuef

This comment has been minimized.

Copy link
Collaborator

@joshuef joshuef commented Nov 5, 2019

also, safe://solid-filemanager has : { 'Content-Type': null } set, which is why it's loading this way.

I'm not sure why it has that set though... When was this uploaded? Maybe by an older CLI?

joshuef added a commit to joshuef/safe_browser that referenced this issue Nov 5, 2019
update tests to better clarify request handling.

For maidsafe#1061
@joshuef

This comment has been minimized.

Copy link
Collaborator

@joshuef joshuef commented Nov 5, 2019

/blog issue sorted. We were missing default key handling for index.html (whereas we handled /index.html)

joshuef added a commit to joshuef/safe_browser that referenced this issue Nov 5, 2019
Enable /index.html or index.html as key entreis in filesmap for default page.

For maidsafe#1061
joshuef added a commit to joshuef/safe_browser that referenced this issue Nov 5, 2019
update tests to better clarify request handling.

For maidsafe#1061
joshuef added a commit to joshuef/safe_browser that referenced this issue Nov 5, 2019
Enable /index.html or index.html as key entreis in filesmap for default page.

For maidsafe#1061
joshuef added a commit that referenced this issue Nov 5, 2019
update tests to better clarify request handling.

For #1061
joshuef added a commit that referenced this issue Nov 5, 2019
Enable /index.html or index.html as key entreis in filesmap for default page.

For #1061
@theWebalyst

This comment has been minimized.

Copy link
Author

@theWebalyst theWebalyst commented Nov 6, 2019

theWebalyst can you check the HTML files and the version of the JS/CSS they are requesting

I think you are correct @joshuef, I'd forgotten that 'sync' doesn't update files unless their size changes, see the following issue. Maybe the following needs to be labelled as a 'bug'?

maidsafe/safe-api#271

also, safe://solid-filemanager has : { 'Content-Type': null } set, which is why it's loading this way.
I'm not sure why it has that set though... When was this uploaded? Maybe by an older CLI?

I'm not sure when or which CLI version this was created with. I'll update the CLI and upload it again to a new NRS name safe://sfm1:

cd ~/src/solid/solid-filemanager
npm run build
safe update
safe auth
safe files put -r build/

Output shows safe CLI is at 0.50

safe nrs create sfm1 -l safe://hnyynyzrkpnzy3swwn8bsaaff8ggtnqr45zfnoe7feqq4ets3u9m8j9u9nbnc

Good, safe://sfm1 loads correctly in SB dev branch d3e6ad5 (and 15.1).

Before I update safe://solid-filemanager to point to the same container, does this explain the difference with SB 15.1 which already loads safe://solid-filemanager correctly (rather than shows the raw HTML as 15.2 does)?

@joshuef

This comment has been minimized.

Copy link
Collaborator

@joshuef joshuef commented Nov 7, 2019

15.1 just assumed everything was text/html. We added proper mimetype detection with 15.2, so this issue was just masked prior, I think.

Good to hear that's going now. 👍

@joshuef joshuef closed this Nov 7, 2019
pWeb1 automation moved this from To do to Ready for QA Nov 7, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
pWeb1
  
Ready for QA
2 participants
You can’t perform that action at this time.