domain name in website/godoc.org

[Will Norris]

Mathieu,

Do you recall the reason for caring about the domain name appearing in the filepath in website/godoc.org?  It looks like it was added in a96ec4e, but I can't figure out why it's needed.  I'm working on trying to implement #1010, and was seeing what in website/godoc.go could be simplified or cleaned up as part of the process.

[Mathieu Lonjaret]

I'm confused. Are you talking about what is now:

domainNames = []string{"perkeep.org", "camlistore.org"}

in website/godoc.go?

(it became domainNames in 02938281318c8dc1fdb0e7a46b543fb7e583a854)

As far as i can tell, we need the domain to:

1) verify that we're serving only for one of these two domains (which
might be overkill, as i think we already filter for that before
reaching this point)
2) being able to strip it out of the path, and derive the part of the
import path that is a "filepath" (as opposed to a domain name).

I think we're inheriting this second point from the logic of the go
stdlib godoc, since we copied the code from there and adapted it for
our needs afair.

Does that answer your question?

[Will Norris]

On Fri, Jan 5, 2018 at 2:22 PM, Mathieu Lonjaret <mathieu....@gmail.com> wrote:

I'm confused. Are you talking about what is now:

domainNames = []string{"perkeep.org", "camlistore.org"}

in website/godoc.go?

(it became domainNames in 02938281318c8dc1fdb0e7a46b543fb7e583a854)

As far as i can tell, we need the domain to:

1) verify that we're serving only for one of these two domains (which
might be overkill, as i think we already filter for that before
reaching this point)

yeah, I think this is overkill.  And also makes it a little harder to test this on localhost when developing :)

 

2) being able to strip it out of the path, and derive the part of the
import path that is a "filepath" (as opposed to a domain name).

I think we're inheriting this second point from the logic of the go
stdlib godoc, since we copied the code from there and adapted it for
our needs afair.

the stdlib godoc doesn't do anything with domains as best as I can tell, which was why I pointed out the CL where it got added here.  Since we know the root directory, it should be relatively easy to strip that out and figure out the correct package path.  Granted, that root flag got added much later, so it makes sense why it wasn't being used.  I'll see if I can achieve everything without needing any notion of domainName(s) in godoc.go.

 

Does that answer your question?

I think so, thanks.

[Mathieu Lonjaret]

On 5 January 2018 at 23:44, Will Norris <wi...@willnorris.com> wrote:
>
> On Fri, Jan 5, 2018 at 2:22 PM, Mathieu Lonjaret
> <mathieu....@gmail.com> wrote:
>>
>> I'm confused. Are you talking about what is now:
>>
>> domainNames = []string{"perkeep.org", "camlistore.org"}
>>
>> in website/godoc.go?
>>
>> (it became domainNames in 02938281318c8dc1fdb0e7a46b543fb7e583a854)
>>
>> As far as i can tell, we need the domain to:
>>
>> 1) verify that we're serving only for one of these two domains (which
>> might be overkill, as i think we already filter for that before
>> reaching this point)
>
>
> yeah, I think this is overkill. And also makes it a little harder to test
> this on localhost when developing :)
>
>>
>> 2) being able to strip it out of the path, and derive the part of the
>> import path that is a "filepath" (as opposed to a domain name).
>>
>> I think we're inheriting this second point from the logic of the go
>> stdlib godoc, since we copied the code from there and adapted it for
>> our needs afair.
>
>
> the stdlib godoc doesn't do anything with domains as best as I can tell,

ok, I don't really remember. it's old :)

> which was why I pointed out the CL where it got added here. Since we know
> the root directory, it should be relatively easy to strip that out and
> figure out the correct package path. Granted, that root flag got added much
> later, so it makes sense why it wasn't being used. I'll see if I can
> achieve everything without needing any notion of domainName(s) in godoc.go.

SGTM if you can.