#1662 closed defect (fixed)

webapi.rst fails to document /file/ and /named/ handlers

Reported by: nejucomo Owned by: marlowe
Priority: major Milestone: 1.9.2
Component: documentation Version: 1.9.1
Keywords: webapi docs Cc: zooko
Launchpad Bug:

Description (last modified by davidsarah)

[Note: This issue affects both the 1.9.0 and 1.9.1 source releases.]

Symptom: I see browser requests for "GET /file/..." but when I grep for '/file' in webapi.rst I see no hits. I have also looked at every hit for "grep -i file" to verify this url path is not mentioned in webapi.rst.

Resolution: Update webapi.rst to describe /file/ urls.

Related Info: It looks as if /file/ may do something similar to /named/ or one may be an older backwards-compatible version of the same feature. If so, clearly document this. If the functional overlap is large and there's no compatibility requirement, we should file a new ticket to remove one of them. If the functionality partially overlaps but is distinct, webapi.rst should make the distinction clear.

Background: I am configuring access control policies based on HTTP method and path for a read-only gateway, so I want webapi.rst to tell me everything necessary for my usecase.

Attachments (1)

ticket-1662.patch (833 bytes) - added by marlowe at 2012-04-10T15:04:13Z.
Adds info on /file

Download all attachments as: .zip

Change History (13)

comment:1 Changed at 2012-01-21T23:44:49Z by nejucomo

In fact, as I continue reading webapi.rst I see the "Other Useful Pages" section begins by saying:

The portion of the web namespace that begins with "/uri" (and "/named") is
dedicated to giving users (both humans and programs) access to the Tahoe
virtual filesystem. The rest of the namespace provides status information
about the state of the Tahoe node.

This is misleading in the face of /file/ requests.

comment:2 Changed at 2012-01-22T01:43:47Z by nejucomo

Analyzing the url namespace (see #1663) shows that /named and /file are handled by different instances of the same class. Unless that code switches logic based on this path segment, the two URL segments are synonymous.

If so, then in webapi.rst where /named is first mentioned, a short note saying "URLs may also use /file/... as a synonym for /named/... would close this ticket.

comment:3 Changed at 2012-01-22T06:13:50Z by davidsarah

  • Component changed from unknown to documentation
  • Keywords webapi docs added
  • Milestone changed from undecided to 1.9.2
  • Owner changed from nobody to somebody

comment:4 Changed at 2012-01-22T06:17:18Z by davidsarah

  • Description modified (diff)
  • Summary changed from webapi.rst fails to mention /file/ handler. to webapi.rst fails to document /file/ and /named/ handlers
  • Version changed from 1.9.0 to 1.9.1

comment:5 Changed at 2012-01-22T12:11:08Z by zooko

  • Cc zooko added

comment:6 Changed at 2012-04-01T00:29:54Z by davidsarah

  • Milestone changed from 1.9.2 to 1.10.0

comment:7 Changed at 2012-04-01T03:22:41Z by marlowe

I can take this one if no one else wants it.

comment:8 Changed at 2012-04-01T04:05:24Z by davidsarah

  • Owner changed from somebody to marlowe

Changed at 2012-04-10T15:04:13Z by marlowe

Adds info on /file

comment:9 Changed at 2012-04-10T15:09:49Z by marlowe

This patch should resolve this ticket as /file and /named are synonyms. Thanks to Brian Warner for assistance with this ticket. The patch is also available as pull request 4 from antagonismorg on Github.

comment:10 Changed at 2012-04-10T16:28:00Z by davidsarah

The WUI uses (that is, includes in directory listings) /file links but not /named links, I think. So should the description in webapi.rst be of /file with /named described as the synonym?

Last edited at 2012-04-10T16:30:52Z by davidsarah (previous) (diff)

comment:11 Changed at 2012-04-10T18:37:37Z by warner

  • Resolution set to fixed
  • Status changed from new to closed

Landed in 589179cf. Thanks!

comment:12 Changed at 2012-05-14T04:59:17Z by davidsarah

  • Milestone changed from 1.10.0 to 1.9.2
Note: See TracTickets for help on using tickets.