Grokbase › Groups › Go › golang-nuts › August 2013
FAQ
I was investigating this question on stack overflow

http://stackoverflow.com/questions/18177419/download-public-file-from-google-drive-golang

And I came to the conclusion that there is either a bug in Go or in
Google's drive service, but I don't know which.

It all hinges on interpretation of '*' in URLs. Looking at the RFC made
my head hurt though ;-)

Would any HTTP or Google experts care to comment?

--
Nick Craig-Wood <nick@craig-wood.com> -- http://www.craig-wood.com/nick

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Francesc Campoy Flores at Aug 12, 2013 at 8:36 pm ⇧
    Hi Nick,

    I contacted someone from the Drive team to have a look at it.
    I'll you posted as soon as I know more.

    Regards,

    On Mon, Aug 12, 2013 at 1:26 PM, Nick Craig-Wood wrote:

    I was investigating this question on stack overflow


    http://stackoverflow.com/questions/18177419/download-public-file-from-google-drive-golang

    And I came to the conclusion that there is either a bug in Go or in
    Google's drive service, but I don't know which.

    It all hinges on interpretation of '*' in URLs. Looking at the RFC made
    my head hurt though ;-)

    Would any HTTP or Google experts care to comment?

    --
    Nick Craig-Wood <nick@craig-wood.com> -- http://www.craig-wood.com/nick

    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.


    --
    --
    Francesc

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dan Kortschak at Aug 12, 2013 at 8:47 pm ⇧
    Looks like both ends are wrong. Go shouldn't be percent encoding it (http://www.ietf.org/rfc/rfc2396.txt section 2.3), and Google drive should be accepting it as encoded. The latter is more significant.
    On 13/08/2013, at 5:56 AM, "Nick Craig-Wood" wrote:

    And I came to the conclusion that there is either a bug in Go or in
    Google's drive service, but I don't know which.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Nick Craig-Wood at Aug 12, 2013 at 9:04 pm ⇧

    On 12/08/13 21:47, Dan Kortschak wrote:
    Looks like both ends are wrong. Go shouldn't be percent encoding it (http://www.ietf.org/rfc/rfc2396.txt section 2.3), and Google drive should be accepting it as encoded. The latter is more significant.
    RFC2396 has been obsoleted by 3986 which doesn't include '*' in that section

    http://tools.ietf.org/html/rfc3986#section-2.3

    --
    Nick Craig-Wood <nick@craig-wood.com> -- http://www.craig-wood.com/nick

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dan Kortschak at Aug 12, 2013 at 9:12 pm ⇧
    Thanks.
    On 13/08/2013, at 6:34 AM, "Nick Craig-Wood" wrote:

    RFC2396 has been obsoleted by 3986 which doesn't include '*' in that section
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dan Kortschak at Aug 12, 2013 at 9:19 pm ⇧
    The same directions are stated in 2.2 of that document.
    On 13/08/2013, at 6:34 AM, "Nick Craig-Wood" wrote:

    RFC2396 has been obsoleted by 3986 which doesn't include '*' in that section

    http://tools.ietf.org/html/rfc3986#section-2.3
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Nick Craig-Wood at Aug 12, 2013 at 9:41 pm ⇧

    On 12/08/13 22:19, Dan Kortschak wrote:
    The same directions are stated in 2.2 of that document.
    http://tools.ietf.org/html/rfc3986#section-2.2

    Ah yes you are right...

    I guess you are referring to this paragraph
    Percent-encoding a reserved character, or decoding a
    percent-encoded octet that corresponds to a reserved character,
    will change how the URI is interpreted by most applications.
    Thus, characters in the reserved set are protected from
    normalization and are therefore safe to be used by scheme-specific
    and producer-specific algorithms for delimiting data subcomponents
    within a URI.
    That seems relatively clear and would indicate that Go is at fault for
    encoding the '*' it got in the Location header thus changing how the URI
    is interpreted.

    However a bit further down we get this
    URI producing applications should percent-encode data octets that
    correspond to characters in the reserved set unless these
    characters are specifically allowed by the URI scheme to represent
    data in that component. If a reserved character is found in a URI
    component and no delimiting role is known for that character, then
    it must be interpreted as representing the data octet
    corresponding to that character's encoding in US-ASCII.
    From which we could argue that Google should have encoded the '*' in the
    original Location: header. I don't know whether '*' is "specifically
    allowed by the URI scheme to represent data in that component" though or
    whether '*' has a "delimiting role".

    --
    Nick Craig-Wood <nick@craig-wood.com> -- http://www.craig-wood.com/nick

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dan Kortschak at Aug 12, 2013 at 10:03 pm ⇧
    Yes, it's the old thing of be correct in what you send, but tolerate people who aren't. Both sides are failing this.
    On 13/08/2013, at 7:11 AM, "Nick Craig-Wood" wrote:
    On 12/08/13 22:19, Dan Kortschak wrote:
    The same directions are stated in 2.2 of that document.
    http://tools.ietf.org/html/rfc3986#section-2.2

    Ah yes you are right...

    I guess you are referring to this paragraph
    Percent-encoding a reserved character, or decoding a
    percent-encoded octet that corresponds to a reserved character,
    will change how the URI is interpreted by most applications.
    Thus, characters in the reserved set are protected from
    normalization and are therefore safe to be used by scheme-specific
    and producer-specific algorithms for delimiting data subcomponents
    within a URI.
    That seems relatively clear and would indicate that Go is at fault for
    encoding the '*' it got in the Location header thus changing how the URI
    is interpreted.

    However a bit further down we get this
    URI producing applications should percent-encode data octets that
    correspond to characters in the reserved set unless these
    characters are specifically allowed by the URI scheme to represent
    data in that component. If a reserved character is found in a URI
    component and no delimiting role is known for that character, then
    it must be interpreted as representing the data octet
    corresponding to that character's encoding in US-ASCII.
    From which we could argue that Google should have encoded the '*' in the
    original Location: header. I don't know whether '*' is "specifically
    allowed by the URI scheme to represent data in that component" though or
    whether '*' has a "delimiting role".

    --
    Nick Craig-Wood <nick@craig-wood.com> -- http://www.craig-wood.com/nick
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedAug 12, '13 at 8:26p
activeAug 12, '13 at 10:03p
posts8
users3
websitegolang.org

3 users in discussion

Dan Kortschak: 4 posts Nick Craig-Wood: 3 posts Francesc Campoy Flores: 1 post

Content

People

Support

Translate

site design / logo © 2022 Grokbase