# Hosting a POD on Github Pages? Yes, it is "possible"!

**URL:** <https://forum.solidproject.org/t/hosting-a-pod-on-github-pages-yes-it-is-possible/3957>\
**Category:** General Discussion\
**Created:** [February 12, 2021, 10:56am UTC](https://forum.solidproject.org/t/hosting-a-pod-on-github-pages-yes-it-is-possible/3957 "2021-02-12T10:56:44Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![NoelDeMartin](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.solidproject.org/noeldemartin/32/3144_2.png) [@NoelDeMartin](https://forum.solidproject.org/u/NoelDeMartin)\
**Post date:** [February 12, 2021, 10:56am UTC](https://forum.solidproject.org/t/hosting-a-pod-on-github-pages-yes-it-is-possible/3957/1 "2021-02-12T10:56:44Z")

</div>

A while ago, I released [a Solid App](https://noeldemartin.github.io/media-kraken/viewer) to display read-only Solid data. The idea was that you could create a container in your POD, make it publicly readable, and share the url with your friends to explore the data with a nice UI.

When I announced this, [I got a comment](https://kosmos.social/@colby/105650506657088266) wondering if this would work with static assets. At the moment, I said that it _should_ be possible, given that from the application’s perspective there is no such concept as “static assets”. The application just issues a request and reads the response, it doesn’t know whether the content is static or generated by a script.

And that’s where I left it at the time.

Today, I thought I’d give it a shot and I did it for real. It was easier than I expected! I created a repository on Github with a bunch of turtle files, and I’m serving them through Github Pages. That’s it! It worked without doing any modifications in my app, which is nice.

This is just a proof concept, and I don’t intend to do more things like this. I still believe it’s better to use full-fledged PODs. But it is food for thought nonetheless, and I thought I’d share it here in case you find it interesting as well.

Here’s the repo with the static turtle files: [https://github.com/NoelDeMartin/favorite-movies/](https://github.com/NoelDeMartin/favorite-movies/)

---

<div class="post-metadata">

**Author:** ![adventure](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.solidproject.org/adventure/32/1152_2.png) [@adventure](https://forum.solidproject.org/u/adventure)\
**Post date:** [February 12, 2021, 11:31am UTC](https://forum.solidproject.org/t/hosting-a-pod-on-github-pages-yes-it-is-possible/3957/2 "2021-02-12T11:31:41Z")

</div>

That’s pretty cool nice job man. I did the same type of thing but a little different about a year ago. [Portal – Solid Home](https://mikeadams1.github.io/Solid-Pod/)

[Mikeadams1.GitHub.io/Solid-Pod](http://Mikeadams1.GitHub.io/Solid-Pod)

---

<div class="post-metadata">

**Author:** ![aveltens](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.solidproject.org/aveltens/32/3987_2.png) [@aveltens](https://forum.solidproject.org/u/aveltens)\
**Post date:** [February 14, 2021, 7:59pm UTC](https://forum.solidproject.org/t/hosting-a-pod-on-github-pages-yes-it-is-possible/3957/3 "2021-02-14T19:59:13Z")

</div>

Interesting, but unfortunately github does not send the correct content-type (`text/turtle`) but `content-type: text/html;` This will probably be an issue for most clients, that rely on content-type to decide e.g. what parser to use

---

<div class="post-metadata">

**Author:** ![NoelDeMartin](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.solidproject.org/noeldemartin/32/3144_2.png) [@NoelDeMartin](https://forum.solidproject.org/u/NoelDeMartin)\
**Post date:** [February 15, 2021, 6:18am UTC](https://forum.solidproject.org/t/hosting-a-pod-on-github-pages-yes-it-is-possible/3957/4 "2021-02-15T06:18:19Z")

</div>

Yeah I noticed that, so it’s not 100% spec compliant. But something I thought while I was trying this is that I think Solid Apps should be as much forgiving as possible.

In this case, they should use the `Accept: text/turtle` header and do the appropriate request following the spec, but if the server response is invalid but still parseable it should work. I compare this to Javascript/HTML “forgiveness”. For example, in HTML you may write `<h1>Hello World<h1>` and while that’s invalid, the browser will still render the page (I don’t even know if this HTML behaviour is described in the spec or it’s just something browsers do, but I think this kind of thing is valuable for interoperability).

Of course, it’s better if every server follows the spec 100% of the time. But, when they don’t, I think it’s useful to have this sort of behaviour.
