Add Content-Disposition http header by nizsheanez · Pull Request #945 · ethersphere/swarm

nizsheanez · 2018-09-21T12:05:23Z

Add Content-Disposition http header

…sphere#527, ethersphere#944) Changed swarm/api.Upload: - when using WaitGroup no reason to use done counter. - f.Close() must be called in Defer - otherwise panic or future added early return will cause leak of file descriptors - use common DetectContentType method - one error was suppressed

…n fallback to extension (ethersphere#944)

acud

Thanks for the contribution 👍 🍺

Please see my comments in the code.

acud · 2018-09-22T10:09:48Z

 	awg := &sync.WaitGroup{}

 	for i, entry := range list {
-		if i >= dcnt+maxParallelFiles {


you have removed important I/O throttling code here. either convert to a worker pattern or preserve as is

Yay! I will revert it.

acud · 2018-09-22T10:12:14Z

 			defer f.Close()
 			if mimeType == "" {
-				mimeType = detectMimeType(file)
+				mimeType = api.DetectContentType(file)


i wonder if we really need to open a new file handle inside of api.DetectContentType. at this point we already have f as an open file handle. maybe we could use that instead. WDYT?

I found problem:

If DetectContentType func will accept *File, then it must current preserve position in file

Here we working with *swarm.File not *os.File which has no Seek() method to save and restore position

It doesn't look possible to get content probe from *swarm.File
Maybe you have an idea?

Ah, *swarm.File it's local file, then i can cast it to Seeker

you can also try to change the swarm.File spec to be

Reader, Closer, Seeker

instead of just ReadCloser. that might make your life easier. but you also might need to move the type around a bit because this will probably generate a circular dependency when you'll try to reference client from api :)

acud · 2018-09-22T10:13:01Z

+	"github.com/ethereum/go-ethereum/log"
+)
+
+// detect content type by file content


comment should follow godoc style:

// DetectContentType by file content with fallback // to file extension and "application/octet-stream"

acud · 2018-09-22T10:16:57Z

+// otherwise by file extension
+// returns "application/octet-stream" in worst case
+func DetectContentType(file string) string {
+	var contentType = "application/octet-stream" // default value


extract to const MIME_OCTET_STREAM = "application/octet-stream", then reuse across the code (DRY)

acud · 2018-09-22T10:20:01Z

+
+	f, err := os.Open(file)
+	if err != nil {
+		log.Warn("detectMimeType: can't open file", "file", file, "err", err)


log.Error - err != nil
also - you're not returning on error (the rest of the code below will continue executing - resulting in an error). if you choose to have another handle opened here - please return an empty string in this code block - the function has to return here.
as mentioned above - i would remove this part and already use the open handle that is created in the enclosing call

acud · 2018-09-22T10:28:35Z

+}
+
+func testDetectCTCreateFile(t *testing.T, fileName, content, expectedContentType string) {
+	path := os.TempDir() + fileName


use ioutil.TempFile instead

acud · 2018-09-22T10:29:22Z

+	testDetectCTCreateFile(t, "file.css", "Lorem Ipsum", "text/css; charset=utf-8")
+}
+
+func testDetectCTCreateFile(t *testing.T, fileName, content, expectedContentType string) {


content param not used - can be removed

acud · 2018-09-22T10:40:00Z

 		defer reader.Close()

 		w.Header().Set("Content-Type", "application/x-tar")
+		w.Header().Set("Content-Disposition", fmt.Sprintf("attachment; filename=\"%s.tar\"", path.Base(r.URL.Path)))


two issues with this:

do not use r.URL as it will contain the entire requested URI e.g. /bzz:/somename.eth/something etc. please use the uri variable above which comes from the middleware that parses the bzz uri. it also has a Path member which you can use to get to the path inside the bzz uri.

there could be a situation where you would be downloading a tarball but the filename might be empty. in that case, you should fallback to the Addr from uri (or untitled)

How about case:

when i upload 1 file, then download it by hash only (without file name in url)
Is there known way to get file name? (As i understand - only way is manifest retrieve)

even if its one file - if there's an enclosing manifest, i think there should be a filename there too (need to double check. in any case - there should be - let's assume that)

acud · 2018-09-22T10:42:45Z

 	}

+	if contentType == "" {
+		contentType = "application/octet-stream"


use const

acud · 2018-09-22T10:42:59Z

 	}

 	w.Header().Set("Content-Type", contentType)
+	w.Header().Set("Content-Disposition", fmt.Sprintf("attachment; filename=\"%s\"", path.Base(r.URL.Path)))


same as above

please amend this - use uri from context instead of request URI. also - provide the filename fallback

…eReview (ethersphere#527, ethersphere#944) Fixes for ethersphere#945 - revert back channel which handle I/O throttling - add tests on real files - add tests when file extension doesn't match content - move code to existing files, no real reason to have dedicated file for such functions - move http headers validation to swarm/api/http package - swarm.Open now checking content of file to detect Content Type

nizsheanez · 2018-09-22T14:45:19Z

Fixed all comments, but I need carefully revisit code about " I/O throttling" tomorrow.

Found edge case:
if .css file has any content - http.DetectContentType return text/plain
looks like in case of text/plain also need to fallback to extension-based check
Do you feel ok with it? Not sure if other edge cases are around...

acud · 2018-09-22T19:22:39Z

hmmm this is starting to suck. we should probably provide an override for all web types because browsers need to have them correctly served, or rather, just have it the way you originally implemented (first file extension, then content based, then fallback to octet-streams. sorry for the zig-zag (i thought that css could be parsed even if its content type is set to text/plain)

nizsheanez · 2018-09-23T02:45:33Z

I will look around to existing webservers tonight. For example Nginx has mime configuration file, default is: https://github.com/nginx/nginx/blob/master/conf/mime.types

For deeper content check https://github.com/h2non/filetype may help, but it looks overkill for me.

nizsheanez · 2018-09-23T06:06:47Z

Here are my thoughts.

About content sniff:

(thank Need more support mime-types. ipfs/kubo#2164 ) - Found that http.DetectContentType is already used when http.ServeContent is invoked. It's mean - need to remove Content-Type detection when we serving content, just double-check that we using http.ServeContent. And I will copy-paste code from there and check if it will work well for Uploading (there are extension check firs... i still feel that we can sniff first and fallback when sniff return "text/plain; charset=utf-8" or "application/octet-stream", but too much open questions - why don't fallback on "text/plain; charset=utf-16be"? or is there any other edge cases? - let's go with ext check first, and maybe open another issue for possible attacks research - because now attacker don't need to put crazy content to .css file, he just can provide any valid Content-Type header and we will trust it).
Fun question: html - What if client sent us header "X-Content-Type-Options=nosniff"?
I saw that swarm/api/testdata has Website serving test, I think need to add non-utf-8 Website to test (but there is a mess :-) .css spec forcing utf-8, while .html and .js allow other encodings :-) )

About extension-based checks:

mime.TypeByExtension using not only builtinTypesLower but also OS preconfigured list (see mime.osInitMime)
Swarm expecting be run in diverse OS/Platforms/Docker - I advise to hardcode own list of extension-based ContentTypes ( at list copy from https://github.com/nginx/nginx/blob/master/conf/mime.types or https://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/conf/mime.types ), just to make Swarm behave similar in different environments. Any cons?

acud · 2018-09-23T06:31:05Z

need to remove Content-Type detection when we serving content, just double-check that we using http.ServeContent. And I will copy-paste code from there and check if it will work well for Uploading.

We don't use it. When fetching content from Swarm - we usually use io.Copy to write into the response, not http.ServeContent. See server.go#HandleBzzGet

Fun question: html - What if client sent us header "X-Content-Type-Options=nosniff"?

Ignore? this is a response header.
We should definitely add this header to our responses. But let's first make sure that this works otherwise we could be breaking stuff (the header should be set only if we have a content type set - to fallback when a scenario of no content-type in manifest occurs)

I saw that swarm/api/testdata has Website serving test, I think need to add non-utf-8 Website to test (but there is a mess :-) .css spec forcing utf-u8, while .html and .js allow other encodings :-) )

Definitely, I also think that adding tests for utf8 content (filenames included) is a must. I'll open an issue for that :)

advise to hardcode own list of extension-based ContentTypes

I completely agree. The list from nginx looks pretty exhaustive for this point in time.

…phere#944) - add hardcoded mime types list - follow stdlib way of ContentType checking

nizsheanez · 2018-09-23T07:28:21Z

Ok. Added. Not solved parts yet:

at swarm up README.md client doesn't send file name (even if send, looks like no place to store it... ) - I will investigate tomorrow

acud · 2018-09-23T07:32:10Z

This is due to another problem and is outside the scope of this issue. I'm already have this issue at mind and it will be taken care of as part of ongoing efforts to refactor and cleanup swarm manifests.

acud · 2018-09-23T07:41:44Z

+// MimeOctetStream default value of http Content-Type header
+const MimeOctetStream = "application/octet-stream"
+
+var once sync.Once // guards initMime


not needed - use init() instead

acud · 2018-09-23T07:42:04Z

+	".avi":  "video/x-msvideo",
+}
+
+func initMime() {


rename to init()

acud · 2018-09-23T07:42:13Z

+
+// DetectContentType by file content, or fallback to file extension
+func DetectContentType(f *os.File) (string, error) {
+	once.Do(initMime)


not necessary

acud · 2018-09-23T07:44:23Z

+	testDetectContentType(t, "file-no-extension", "Lorem Ipsum", "text/plain; charset=utf-8")
+	testDetectContentType(t, "file-no-extension-no-content", "", "text/plain; charset=utf-8")
+
+	// TODO: research, define behavior when content doesn't mach file extension. Now just rely on extension.


remove comment

acud · 2018-09-23T07:48:07Z

+				return
+			}
+
+			if err := wait(ctx); err != nil {


I'd rather have this wait() before the mime detection happens, as in the original code

acud · 2018-09-23T07:49:18Z

 	}

 	w.Header().Set("Content-Type", contentType)
+	w.Header().Set("Content-Disposition", fmt.Sprintf("attachment; filename=\"%s\"", path.Base(r.URL.Path)))


please amend this - use uri from context instead of request URI. also - provide the filename fallback

acud · 2018-09-23T07:49:58Z

 	return strings.Contains(err.Error(), api.ErrDecrypt.Error())
 }
+
+func ValidateContentTypeHeader(r *http.Request) (string, error) {


@lmars what is your input on this?

I'm not really sure what the purpose of this code is?

validating incoming mime type on upload from header, to make sure that the input we're getting is correct before storing it in a manifest - just to make sure we are on par with IETF RFCs

acud · 2018-09-23T07:50:30Z

@@ -0,0 +1 @@
+package api


remove file

…where possible (ethersphere#527, ethersphere#944) - simplified I/O throttling by semaphore primitive - don't use URL from request, use parsed Swarm uri for file name detection

nizsheanez · 2018-09-23T09:58:57Z

Fixed all comments.

Question: do i need to delete force of "application/octet-stream" in bzz-resource: https://github.com/ethersphere/go-ethereum/blob/master/swarm/api/http/server.go#L659 ?
Next line http.ServeContent must sniff content well.

acud · 2018-09-23T10:09:26Z

Great work on this! :)
the code is fine as-is - http.ServeHttp tries to sniff the content just in the case that Content-Type isn't set (L191-L193)

nizsheanez · 2018-09-23T10:28:41Z

Thank you for on-boarding.

lmars · 2018-09-23T22:04:51Z

+// MimeOctetStream default value of http Content-Type header
+const MimeOctetStream = "application/octet-stream"
+
+// builtinTypesLower stores copy of https://github.com/nginx/nginx/blob/master/conf/mime.types


I personally feel this mime.types file should be vendored (or just copied into a Go file) to make it easy to keep in-sync with the upstream file.

I also think it should be clear why this is here (if I saw this I'd probably just think it was unnecessary because the Go mime package does the right thing in pretty much all cases).

By vendoring of mime.types file - you mean write some go generate command to parse it and gen code? Same approach as here https://github.com/bradrydzewski/go-mimetype (it based on mailcap instead of nginx, but there is same mime file) ?

Something like that, yes, which would make it much easier to keep in sync, and more obvious where the types come from.

@lmars do you think the overhead is justified in this case? I mean, the mime types base list doesn't fluctuate that much.

lmars · 2018-09-23T22:07:33Z

+
+func init() {
+	for ext, t := range builtinTypesLower {
+		mime.AddExtensionType(ext, t)


This should panic if there is an error (in case some one adds an extension or mime type that doesn't parse)

lmars · 2018-09-23T22:10:34Z

+	}
+}
+
+// DetectContentType by file content, or fallback to file extension


This comment is not consistent with what the method actually does.

lmars · 2018-09-23T22:17:50Z

+	if err != nil {
+		t.Fatal(err)
+	}
+	defer os.Remove(f.Name())


You could avoid the need for a temp file by modifying DetectContentType to take (filename string, data io.ReadSeeker) and just use a bytes.Reader in the tests.

indeed, it will simplify everything

lmars · 2018-09-23T22:19:45Z

+
+func TestDetectContentType(t *testing.T) {
+	// internally use http.DetectContentType, so here are test cases only about fallback to file extension check
+	testDetectContentType(t, "file.css", "body {background-color: orange}", "text/css; charset=utf-8")


This should use t.Run to isolate each test.

lmars · 2018-09-23T22:25:34Z

+	if found := path.Base(uri.Path); found != "" && found != "." && found != "/" {
+		fileName = found
+	}
+	w.Header().Set("Content-Disposition", fmt.Sprintf("attachment; filename=\"%s\"", fileName))


Are you sure we want to make all files attachments? If I go to bzz://mysite.eth/index.html in my browser, I expect to see the HTML in the browser, not download it to a local file.

oh, how much you right. Right now i will change it to:
Content-Disposition: inline; filename="example.html"
But i will rise question in Gitter - maybe exist some cases when attachment make sense, for example in S3 owner can add any headers to it's file/folder by UI, and Content-Disposition: attachment too.

lmars · 2018-09-23T22:27:39Z

 	return strings.Contains(err.Error(), api.ErrDecrypt.Error())
 }
+
+func ValidateContentTypeHeader(r *http.Request) (string, error) {


I'm not really sure what the purpose of this code is?

…sniffer work (ethersphere#527, ethersphere#944)

…on only since go1.11, a bit of copy-paste (ethersphere#527, ethersphere#944)

nizsheanez · 2018-09-24T03:57:58Z

2 more changes:

Can't use ioutil.TempFile - it returns predictable extension only since go1.11 (see io/ioutil: predictable suffix for TempFile golang/go#4896), solution - a bit of copy-paste (return Content-Disposition header alongside content #527, change file mime type detection to magic number #944)
Go returns different ContentType for .md files on Debian and OSx (in image golang:1.11 and golang:1.11-alpine it returns "text/markdown", but on OSx - "text/plain"). As i understand - spec about "text/markdown" exists by not officially accepted yet (https://tools.ietf.org/html/rfc7763). I added .md to our list anyway (feel free to deny if you don't like)

…on only since go1.11, a bit of copy-paste (ethersphere#527, ethersphere#944) - added text/markdown content type

nizsheanez · 2018-09-24T08:16:47Z

@lmars about I'm not really sure what the purpose of this code is? - I just moved Content-Type header check from 3 places to that function (ValidateContentTypeHeader). Do you feel it unnecessary or need rename to RequireContentTypeHeader?

…ion from attachment to inline (ethersphere#527, ethersphere#944) - If I go to bzz://mysite.eth/index.html in my browser, I expect to see the HTML in the browser, not download it to a local file.

zelig · 2018-09-24T13:23:49Z

@nizsheanez @justelad status? shall we move this to main repo?

acud · 2018-09-24T13:29:38Z

@zelig let's first resolve all issues here then squash+reopen on upstream

nizsheanez · 2018-09-24T13:35:58Z

Status: fixed all CR comments except one:

From Imars: "I personally feel this mime.types file should be vendored (or just copied into a Go file) to make it easy to keep in-sync with the upstream file." - Waiting for hist reply now.
I have airplane tomorrow, will push something about it - after tomorrow.

acud · 2018-09-26T06:08:44Z

+		t.Fatalf("Content-Type header expected: application/x-tar, got: %s", h)
+	}
+
+	// See header to suggest file name for Browsers


remove comment

acud · 2018-09-26T06:10:39Z

+		if found := path.Base(uri.Path); found != "" && found != "." && found != "/" {
+			fileName = found
+		}
+		w.Header().Set("Content-Disposition", fmt.Sprintf("inline; filename=\"%s.tar\"", fileName))


i am wondering - maybe in this case we should actually send an attachment header. @lmars?

acud · 2018-09-26T06:14:05Z

+	if found := path.Base(uri.Path); found != "" && found != "." && found != "/" {
+		fileName = found
+	}
+	w.Header().Set("Content-Disposition", fmt.Sprintf("inline; filename=\"%s\"", fileName))


@lmars I think this should be:
if contentType == 'application/*' - return attachment
else return inline.
WDYT?

Worry about "application/pdf" and "application/rss+xml", I'm personally fine if .pdf opening in browser (re-checked, browsers do download .pdf file with Content-Disposition: attachment; file="name.pdf" header, and only Safari on my Mac auto-open it in Preview).

i've seen the rss issue too but i think its a non-issue as its a machine readable format and is not supposed to be read by the user as-is (AFAIK)

On my MacBook:

With inline:

Firefox: has Built-in RSS reader. it displays RSS in readable way and has "subscribe" button.

Safari: forward link to installed RSS Reader app.

With attachment:

Firefox: download file

Safari: forward link to installed RSS Reader app

Looks like we breaking some UX here.

ok - keep it as it is for now (inline it)

nizsheanez · 2018-09-26T10:17:09Z

Added generator based on mime.types file as lmars recommended.

lmars · 2018-09-26T10:37:03Z

+// mime.types file provided by mailcap, which follow https://www.iana.org/assignments/media-types/media-types.xhtml
+//
+// Get last version of mime.types file by:
+// docker run --rm -v $(pwd):/tmp alpine:edge /bin/sh -c "apk add -U mailcap; mv /etc/mime.types /tmp"


This now seems to do exactly what the package you linked to does (i.e. https://github.com/bradrydzewski/go-mimetype), should we not just use that package?

That package looks unmaintained, but let me try to rise PR there, here is list of differences:

go-mimetype doesn't fail if mime.AddExtensionType returns error

outdated mime.types file

Ok, I don't mean for you to go back and forth on this. I assumed you didn't want to use that package because you wanted to use nginx mime types, but if we want to use the same method as that package then we should try and PR upstream (the maintainer looks active on other projects)

Ah, just that mime.types file easier to parse. File from nginx has nginx.config format you can see there are some bracers: https://github.com/nginx/nginx/blob/master/conf/mime.types

No problem, already created PR: bradrydzewski/go-mimetype#1

Anyway we still discussing about Content-Disposition

…ator added, based on mailcap mime.types file (ethersphere#527, ethersphere#944)

lmars · 2018-09-26T13:09:23Z

@nizsheanez @justelad it seems this PR is covering two things:

Improved detection and validation of Content-Type
Add Content-Disposition

It seems we've got to a good solution for improving Content-Type, but I don't think it's clear what problem we are trying to solve with the Content-Disposition header.

What is driving the decision to add this Content-Disposition header? Is it a user-requested feature? If it has been requested, I personally think we should expose some form of option to the user to allow them to set Content-Disposition if they want, but I don't think Swarm should be trying to preempt how the user wants their content to be served (either inline or as an attachment).

acud · 2018-09-26T13:34:05Z

@lmars this solves the problem that the browser does not always know under which filename to save swarm content and this is rather annoying.
Content-Disposition solves this.
No user requested this. I noticed this problem and opened the ticket on my own accord.

nizsheanez · 2018-09-26T14:22:17Z

I agree that Content-Disposition: attachment must be configurable by user - Because we discovered too much edge cases already (maybe even on MRU level instead of file, but i'm not sure).

Adding Content-Disposition: inline - solved browser does not always know under which filename to save swarm content problem (with one exception: when client uploading single file - it doesn't send to server fileName. Justelad, says that it's out of scope and he will fix it later: #945 (comment) )

@justelad , now I need to do squash and open new PR with good description?

acud · 2018-09-28T06:35:46Z

@nizsheanez many thanks for this comprehensive PR!

Please squash all commits and reopen this PR against ethereum/master with a description.

nizsheanez · 2018-09-28T15:31:07Z

Done ethereum/go-ethereum#17782

cmd/swarm, swarm/api/http: Suggest Browser file name (ethersphere#527)

9c7f0d1

Add Content-Disposition http header

nizsheanez mentioned this pull request Sep 21, 2018

return Content-Disposition header alongside content #527

Closed

nizsheanez mentioned this pull request Sep 22, 2018

change file mime type detection to magic number #944

Closed

acud assigned acud and unassigned acud Sep 22, 2018

acud added in progress http/rpc/ipc manifest labels Sep 22, 2018

nizsheanez added 4 commits September 22, 2018 15:21

swarm/api: Content-Type detection - do content-based check first, the…

76792bc

…n fallback to extension (ethersphere#944)

swarm/api, swarm/http: Content-Type validation (ethersphere#527)

ae075b6

swarm/api/http: Content-Type validation (ethersphere#527)

1d8c2b3

swarm/api/http: Run goimports (ethersphere#527)

58f1a63

acud suggested changes Sep 22, 2018

View reviewed changes

acud assigned acud and unassigned acud Sep 22, 2018

swarm/api: Add predefined list of mime types (ethersphere#527, ethers…

c4c1b54

…phere#944) - add hardcoded mime types list - follow stdlib way of ContentType checking

acud suggested changes Sep 23, 2018

View reviewed changes

swarm/api, swarm/api/http: simplify I/O throttling and use file name …

e41ea4e

…where possible (ethersphere#527, ethersphere#944) - simplified I/O throttling by semaphore primitive - don't use URL from request, use parsed Swarm uri for file name detection

acud removed the in progress label Sep 23, 2018

acud added the ready for review label Sep 23, 2018

lmars reviewed Sep 23, 2018

View reviewed changes

swarm/api/http: Don't force Content-Type where possible, let builtin …

b632a2b

…sniffer work (ethersphere#527, ethersphere#944)

nizsheanez force-pushed the add-content-disposition-http-header branch from 7c3c4c1 to b632a2b Compare September 24, 2018 02:09

swarm/api: Can't use ioutil.TempFile - it returns predictable extensi…

8dc449a

…on only since go1.11, a bit of copy-paste (ethersphere#527, ethersphere#944)

swarm/api: Can't use ioutil.TempFile - it returns predictable extensi…

afb750a

…on only since go1.11, a bit of copy-paste (ethersphere#527, ethersphere#944) - added text/markdown content type

nizsheanez force-pushed the add-content-disposition-http-header branch from d3e2886 to afb750a Compare September 24, 2018 04:19

swarm/api, swarm/api/client, swarm/api/http: Changed Content-Disposit…

1e87e3d

…ion from attachment to inline (ethersphere#527, ethersphere#944) - If I go to bzz://mysite.eth/index.html in my browser, I expect to see the HTML in the browser, not download it to a local file.

nizsheanez force-pushed the add-content-disposition-http-header branch from 08bc172 to 1e87e3d Compare September 24, 2018 08:49

acud reviewed Sep 26, 2018

View reviewed changes

lmars reviewed Sep 26, 2018

View reviewed changes

cmd/swarm/mimegen, swarm/api, swarm/api/http, Makefile: Mimegen gener…

5c00804

…ator added, based on mailcap mime.types file (ethersphere#527, ethersphere#944)

nizsheanez force-pushed the add-content-disposition-http-header branch from e89f0ef to 5c00804 Compare September 26, 2018 11:15

acud approved these changes Sep 28, 2018

View reviewed changes

nizsheanez mentioned this pull request Sep 28, 2018

swarm: cross-platform Content-Type detection, and suggest for browser filename ethereum/go-ethereum#17782

Merged

acud closed this Sep 29, 2018

Conversation

nizsheanez commented Sep 21, 2018

Uh oh!

acud left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nizsheanez commented Sep 22, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

acud commented Sep 22, 2018

Uh oh!

nizsheanez commented Sep 23, 2018

Uh oh!

nizsheanez commented Sep 23, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

acud commented Sep 23, 2018

Uh oh!

nizsheanez commented Sep 23, 2018

Uh oh!

acud commented Sep 23, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nizsheanez commented Sep 23, 2018

Uh oh!

acud commented Sep 23, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

nizsheanez commented Sep 22, 2018 •

edited

Loading

nizsheanez commented Sep 23, 2018 •

edited

Loading

acud commented Sep 23, 2018 •

edited

Loading