Submitted by Regan Murley:
We were reviewing some of the CF docs and found what looks like a typo or I feel this is at least rather ambiguous if someone is skipping around to different sections using the anchors rather than reading every paragraph:

https://developer.rackspace.com/docs/cloud-files/v1/developer-guide/#cdn-enable-and-cdn-disable-a-container

Has the following text:

Before a container can be CDN-enabled, it must exist in the storage system. To CDN-enable the container, perform a PUT request against it using the publicURL noted in the service catalog for Cloud Files during authentication, and set the X-CDN-Enabled header to True.

Which should probably read:

Before a container can be CDN-enabled, it must exist in the storage system. To CDN-enable the container, perform a PUT request against it using the publicURL noted in the service catalog for cloudFilesCDN during authentication, and set the X-CDN-Enabled header to True.

Both cloud files and cloud files CDN endpoints have a "publicURL" value and it's easy to confuse the two. The other sections have it listed more like how we would expect it to read:

https://developer.rackspace.com/docs/cloud-files/v1/developer-guide/#list-cdn-enabled-containers

See the markup and comments in the attached Word doc for my suggested edits for the release notes. Please let me know if you have any questions. Thanks!

Cloud Files Release Notes_editsKH.docx

Hi Catherine,
Apologies if you are not the go-to for these issues currently, let me know where to send this if I'm mistaken.

The following section of the Cloud Files API docs contains a defunct link - the content is under another subdirectory:

https://developer.rackspace.com/docs/cloud-files/v1/storage-api-reference/container-services-operations/#create-or-update-container-metadata

specifically this box:

For information about adding metadata for the following purposes, see Get object content and metadata:
Container quotas
Access log delivery
"Access log delivery" is not in the section this "get object content and metadata" link jumps you to. It's here under the use cases:

https://developer.rackspace.com/docs/cloud-files/v1/use-cases/additional-container-services-information/#access-log-delivery

I only know because I just had a minor panic attack trying to locate it just now to prove that the log explanation ever existed. It's very late in my day. :)

Let me know if I can help with anything else. Thanks!
-Regan Murley

The side navigation bar stays static at the top of the page so if you're scrolling on a long page, there's no easy way to navigate elsewhere without scrolling back up to the top.

(Not sure if this was intentional, hence the question mark in the issue title)

Hey folks,

I was going to initiate a pull request for this one, but I'm not sure of what the information should be reflected, since some I found to be missing from the github repo as well as in the live API docs.

If we look at the creating-large-objects.rst section of the Cloud Files API docs, we can see that in the section proceeding 'Example: Upload a segment of a large object: HTTP request'. Many of the output examples are showing single letter like 'w' , or 's', this strikes me as something that is not intended.

https://github.com/rackerlabs/docs-cloud-files/blob/5451cce9e2c623015c701ac676153966608ef0ca/api-docs/use-cases/additional-storage/creating-large-objects.rst

I believe that this may have been like this for a while. Please would you be so kind to help me revert a previous version of this that had the correct output for those sections?

Cheers &
Best wishes,
Adam

RST has a "definition list" function that looks like this:

token ID
    The token ID value is required to confirm your identity each
    time you access the service. Include it in the ``X-Auth-Token`` header
    for each API request.

    The ``expires`` attribute indicates the date and time that the token will
    expire, unless it is revoked before the expiration. To get a new token,
    submit another authentication request. For more information, see
    :rax-devdocs:`Manage authentication tokens
    <cloud-identity/v2/getting-started/manage-auth-tokens>`.

tenant ID
    The tenant ID provides your account number. For most Rackspace Cloud
    service APIs, the tenant ID is appended to the API endpoint in the service
    catalog automatically. For Rackspace Cloud services, the tenant ID has the
    same value as the tenant name.

endpoint
    The API endpoint provides the URL that you use to access the API service.
    For guidance on choosing an endpoint, see
    :ref:`Service access <service-access>`.

This is what it should look like:

This what it's doing:

Refactor API Guide checklist

Use the following checklist to guide and track the refactoring work for
each Developer Guide. If you have questions, open a docs-common issue.

When you build the refactored Sphinx project, use the make clean html command to build chunked content. Before you begin refactoring, review the restructured text fixes.

Important: If the project contains additional source files or content significantly
different than the template, add a link to the source in Issue #62 in the docs-common repo.

RST coding syntax fixes

Refactoring the API guides gives us a chance to make our RST source files comply with coding best practices. You can make the following changes when you are refactoring, or make the updates in a separate effort.

• Wrap all lines to 79 characters.
• Ensure that heading separator lines are the same length as the title

    ====
    Test
    ====

• Use the following symbols for heading separators:
  • H1: over and underline =
  • H2: ~
  • H3: -
  • H4: ^

In the same file, the header levels must be in sequential order. If they aren't, you get the following error when you run the Sphinx build: SEVERE/4) Title level inconsistent.

Tip: If you are using the Atom editor, you can configure the soft wrap feature to reflow text
to 79 characters with a keybinding:

• Set the line length:
  • Click Atom > Preferences > Settings.
  • Change the Preferred Line Length to 79.
  • Make sure that Soft wrap at Preferred Line length is selected.
  • Do not select the Soft wrap selection.
• Reflow text that exceeds 79 characters.
  • Select the line or paragraph.
  • Click alt+cmd+q to reflow the text. If text is indented or has special formatting,
    you have to adjust the text manually.

Note: Don't worry about the line length in code samples or tables for now.

Configuration updates (conf.py)

• Replace everything above the ## -- General configuration line with the first 32 lines from
  the conf.py in the API Guide template.
• Change deconst builder configuration to deconst-serial to build chunked html.
  builder = 'deconst-serial'
#builder = 'deconst-single
• Add the spelling checker extension after the extension modules configuration.
• Ensure that extlinks library matches the one in conf.py template.
• Add sphinx-rtd-template to improve template for local builds.
• Add requirements.txt to the root directory to support local builds
• Update titles to remove "Developer Guide". Follow title pattern in conf.py template.
• Verify that configuration settings match those in the conf.py for the API Guide template.
• Check conf.py syntax with pep8. Fix errors.

Tip: To catch errors inline, configure Atom for Python.

After you complete the conf.py updates, run the Sphinx build (make clean html) to test that the build still works: make clean html. Resolve any errors.

Note: If the Sphinx build doesn't run, follow the build from source instructions to install the required dependencies.

Overview updates

When you refactor the content in the overview source files, you relocate the content and delete the overview folder and files.

• Move the following files to the root directory of the Sphinx project: additional-resources.rst,service-updates.rst
• Copy the About API description from overview/index.rst to the beginning of the main index.rst file so that the API description is the first information in the API Guide.
• Move any other files in the overview folder to the root directory, and either integrate the content into another topic, or add the file in the index.rst toctree where it makes sense.
• Delete the overview folder.
• Update the index.rst toctree directive:
  • Delete overview/index.rst.
  • Add additional-resources and service-updates after the release-notes file
    and before the copyright as shown in the index.rst template.

After you complete the overview updates, run the local Sphinx build. Resolve any errors. Then, run the following command to review the local build output to verify that the API description, Additional resources and Service updates content renders correctly: open _build/html/index.html

Getting started updates

For the Getting Started section, use the following instructions to refactor the common content and the product-specific Getting Started content.

Update common gs-section

• Copy the common-gs folder with the [API Guide template files].(https://github.com/rackerlabs/docs-common/tree/master/api-guide-template/common-gs)

• View the diff of the new content against your existing content.

  If you have any content that's not included in the common content, determine whether it
  needs to be added to the template. If not, then put the content in a different location so
  that the common content is the same across all API Guides. If necessary, open a
  docs-common issue issue
  to update the template or determine how to handle the custom content. All common-gs
  content must be the same.

The changes made to the common-gs content include the following:

• Adjust heading levels in auth-using-curl.rst to move everything up one level.
• Update get-credentials to move heading up a level and remove Cloud Control Panel login info.
• How-to-use-curl minor edits and add Windows cURL info.
• Wrap all lines at 79 characters and remove trailing spaces.
• Miscellaneous editorial improvements.

Update Getting Started section

• Add the get-credentials-include.rst file to the getting-started folder. This file embeds the common get-credentials.rst topic at the H2 level.
• Move concepts.rst file from the root directory to the getting-started folder.
• Update authentication.rst to append Identity endpoint information at end of last paragraph. See authentication template.
• Update send-request-ovw.rst to change intro sentence to refer to section and
  remove link definition for Cloud Control panel. See Send API request template.
• Update index.rst (See template.)
  • Copy the heading and opening paragraph from getting-started.rst to the
    top of getting-started/index.rst.
  • Remove bold format from heading.
  • Add the prerequisite information after the opening paragraph following the getting-started topic template
  • Update toctree specification:
    * Add get-credentials-include file at the top of the list.
    * Remove prerequisites topic.
    * Add concepts.rst after authentication.rst topic.

After you complete the Getting Started updates, rebuild the Sphinx project. Resolve any errors. Then, review the local build output to verify that the content renders correcctly and that it matches the Getting started template.

Developer Guide updates

The Developer Guide refactoring moves the content from the Developer Guide introduction to the main index.rst file.

• index.rst updates:
  - [x] Copy Developer Guide intro about audience and prerequisite knowledge to root index.rst intro before the paragraph with links to the sections of the API documentation. See root index.rst template.
  - [x] Remove the link to the Developer Guide section.
  - [x] Update the toctree specification to remove developer-guide
• Delete the developer-guide.rst file from the root directory

After you complete the Developer Guide updates, rebuild the Sphinx project. Resolve any errors. Then, preview the local build output to verify that the Developer Guide section was removed.

General API info updates

When you refactor the General API section, the main changes are removing the authentication
topic and adjusting the heading levels. You'll also need to change some common file names and content to match the common content in the API Guide template. Some of these changes are included in the instructions, but there are too many to document in detail. Be careful when you make these changes, some projects have custom information that differs from other projects.

Important: If you have common files in your source that are not in the template directory or significantly deviate from the template source file, add a link to the Github source for that file to the General API info source file issue. This list will help us review and improve the General API Info content and determine whether it needs to be included in the API template.

• Change index.rst heading level to

=======================
General API information
=======================

• Update general-api-info/index.rstto append a reference to the Getting Started authentication section. (See General API info index.rst #template.)
• Update the toctree directive to remove the filename for the authentication topic.
• Delete the authentication source file from the general-api-info directory.
• Change headings in sub-topics to H1 and H2 (~~~~~) per template.
• Rename service-access-endpoints.rst to service-access.rst and match content to template version.
• Compare General API Information source files to the source in the API template directory, and update to match common content where possible.

After you complete the Getting Started updates, rebuild the Sphinx project. Resolve any errors, Then, review the local build output to verify that the content renders correctly and that it matches the General API information template.

API Reference updates

When you refactor the API reference section, the main changes are relocating the api-reference heading to api-reference/index.rst topic and adjusting the heading levels in the methods section.

• Rename api-operations folder to api-reference
• Update the exclude_pattern configuration in conf.py with the new name.
• Update api-reference/index.rst to follow template
• Check api-reference.rst in the root directory to make sure it doesn't have any additional
  information not included in the updated api-reference/index.rst file. If no extra content, delete the file. If additional content is included and still needed, move it to the index.rst file.
• Update root index.rst with new path to api-reference/index.rst.
• Change api resource topic heading levels to h1 (====).
• Change api method heading levels to h2 (~~~~~~~~~).
• Change request and response heading levels to h3 (-------).

After you complete these updates, rebuild the Sphinx project. Resolve any errors. Then, review the local build output to verify that the content renders correctly and that it matches the API Reference API reference template.

Release notes updates

When you refactor the Release notes section, the main change is relocating the Release notes heading and introduction to release-notes/index.rst, moving the release note topics to a sub-folder, and including all release notes topic in index.rst. You also need to add the new release-notes folder to the exclude_patterns specification in the Sphinx configuration file, conf.py.

• Move release-notes.rst to release-notes folder and rename to index.rst.
• Set up all release note content to render in a single topic.
• Create a releases sub-folder in the release-notes directory.
• Move individual release notes files into the releases folder.
• Update release-notes/index.rst to include all release files.
  Use the .. include:: directive
• ``release-notes/index.rst updates:
• Change refid to .._release-notes-collection:.
• Update release-notes/index.rst to include all release files
  using the .. include:: directive. See template.
• Remove bold format from title.
• Main index.rst updates
  • Update link to release note section to use new
    refid = release-notes-collection.
  • Update toctree specification with path to release-notes/index
• Update the exclude_patterns specification in the Sphinx configuration file conf.py to
  add the release-notes/releases pathr.

After you complete the updates, rebuild the Sphinx project. Resolve any errors. Then, review the local build output to verify that the content renders correctly and that it matches the API Guide Release notes template.

Root index.rst updates

Many of the refactoring changes in the root index.rst file were completed when you refactored earlier section. These instructions provide a summary of the changes so you can verify them.

• Ensure the first paragraph provides information about audience and prerequisite knowledge like the root index.rst template.
• Update the links to API Guide sections
  • Remove Developer-Guide
  • Change release-notes ref ID to release-notes-collection
• Update files in toctree directive to follow this pattern:

   Product name v# <https://developer.rackspace.com/docs/cloud-load-balancers/v1/>
   getting-started/index
   general-api-info/index
   api-reference/index
   release-notes/index
   service-updates
   additional-resources
   copyright

Changes include:

• Add the following file names:
  • additional-resources.rst
  • service-updates.rst
• Delete the following file names:
  • getting-started.rst topic
  • prerequisites-for-using-api.rst
  • concepts.rst
  • developer-guide.rst
  • api-reference.rst

Note: If your project contains additional source files not included in this list, add them to Issue #62 in the docs-common repo. Include them in the content architecture where it makes sense. IA team can review.

Next steps

After you complete the refactoring work, complete the following steps to submit the changes for review:

1. To change the API documentation template for your project, update the routes.d file in the nexus-control repository to change the template from docs-singlepage.html to user-guide.html.
2. After the nexus-control PR has been merged, submit a PR with your refactoring changes against your upstream repository.
3. Follow the review instructions.

Form storageops slack channel on 7/13/2016:
Catherine Richardson
10:37 AM @hurricanerix: @ahale I see a doc change from yesterday for
https://developer.rackspace.com/docs/cloud-files/v1/developer-guide/#list-cdn-enabled-containers. I'll change it to say that it list any containers that are currently or have ever been CDN-enabled.

1. On https://developer.rackspace.com/docs/cloud-files/v1/developer-guide/#document-getting-started/authenticate
2. Resize width of the browser (I was on Chrome).
   

I am working on creating a temporary URL to access our files using the API. I have read through this section numerous time: https://developer.rackspace.com/docs/cloud-files/quickstart/#get-object

I am hung up on the the line: bin/swift-temp-url GET 3600 $ENDPOINT/{containerName}/{objectName} {arbitraryKey}
Above it the comments say: "Create the temp_url_sig and temp_url query parameter values. OpenStack Object Storage provides the swift-temp-url script that auto-generates
the temp_url_sig and temp_url_expires query parameters. For example, you might run this command:"
What is the bin/swift-temp-url bit? I am assuming the last part starting with $ENDPOINT is the URL we hit with the GET request. And is the 3600 the port we are supposed to be using?

• Add disclaimer to Developer Docs Trello card
• Update _deconst.json to add variables to enable Edit on GitHub feature Trello card
• Remove SLA and pricing topic from docs Trello card

Maybe just a copy/paste issue, but this page refers to "Cloud Block Storage" in the opening sentence, which refers to cinder (block storage), not swift (object storage).

Kelly edited the contributor collateral, and we added a CONTRIBUTING.md so that users get the link to contributor instructions when working in the repo.

Using [Cloud Identity](https://github.com/rackerlabs/docs-cloud-identity] as a model, update the info for contributors:

• Revise README.md
• Add CONTRIBUTING.md
• Add GITHUBING.md

Update all links and naming to match product.

@rackerlabs/bureaucrats

Hello admins,

The Information Development Team is migrating all documentation repositories published using Deconst to a new publishing platform stack.

This change is to improve functionality, build times, and longevity of the platform.

Things that won't change:

• How you contribute to this repository
• No downtime
• No GitHub configuration changes

Changes to expect:

• Build checks are now produced by netlify
• Build previews can be accessed by clicking "Details" to the right of "netlify/path/deploy-preview"

The migration has already started and we are unable to provide the exact date that this repo is to be migrated.
If you have questions or concerns please reach out to myself or Robb Romans.

Thanks, William Loy

The example has X-Account-Meta-Subject so watchout for the under bar instead of dash. 👓

For Purge an object from a CDN-enabled container - the Purge an Object title for the command response is formatting like this: Purge an object from a CDN-enabled container response*

Should be bold and remove the *

From storageops slack channel on 7/13:

David Goetz
5:06 PM rich0261: i think you can delete them now (as of like 2 years ago 😛 ) to get them out of the listings
Sean Embry
5:08 PM I tried that but I get a 405
David Goetz
5:09 PM you have to send some header. one sec
5:09 sean4747: try sending a DELETE with a "x-remove-cdn-container: t” header
Sean Embry
5:10 PM OK
5:10 You sir, simply rock and roll. That did it.
@david.goetz: I will also document DELETE with a "x-remove-cdn-container: ” header unless you think I shouldn't (in the API docs at developer.rackspace.com).
David Goetz
10:41 AM catherine: that would be cool. just remember its just a DELETE to the cdn management API

Not sure if this is the intent, but the text says PUT command but the example has a POST:

http://staging.developer.rackspace.com/docs-cloud-files/#account-to-account-copy

Then based on the formatting I'm not sure if the numbered list is a continuation of the copy above or if it's meant to be its own list and should start over at 1? Here's a screenshot in case it helps to see in context.

the current standard doc structure has top level dir with your product name. within that is (at least) a dir api-docs. Under that live all the RST files and dirs like conf.py, developerguide.rst and so on. Cloud Files has the old structure with rst/dev-guide.

Also the methods are not in one methods dir and there are two separate index files for operations, rather than one in the api-operations directory.

Hey Racker,

I've noticed that recently the API docs format has been updated. Now the sections are condensed into expandable menu's, it's much harder to get an overview, when looking for something specific, without an expand all button.

I noticed there is no expand all button, I believe this affects all docs , not just cloud files. From a usability perspective it would be really neat to have this feature to make it easier for rackers and non rackers searching the API docs.

Cheers &

Best wishes,
Adam

Missing link in http://staging.developer.rackspace.com/docs-cloud-files/#create-or-update-container-metadata

Also I'm not sure about the spacing going on there, so take a look. 👀 :)

Update the content URL for refactored API documentation

• Fork and clone the nexus-control to your local system.
• Remove developer-guide from the route configured for the content.

  • Update the nexus-control configuration file as shown in the following example:

    Original: "/docs/cloud-load-balancers/v1/": "https://github.com/rackerlabs/docs-cloud-load-balancers/v1/developer-guide",

    Updated:``"/docs/cloud-load-balancers/v1/": "https://github.com/rackerlabs/docs-cloud-load-balancers/v1/",

    Notes:

    The value on the left is the path to deploy content. The value to the right of the : is the unique
    content ID for the Sphinx project. The content ID must match the "contentIDBase" value in the
    _deconst.json file in the documentation source directory. See Configure development and production builds for Sphinx projects.

• Update the deploy URL in the route configuration file to match the one in the nexus-control configuration file.
• Create a redirect rule for the original URL.

  • Edit the rewrites file to add a redirect rule for the original URL as shown in the following example:

      {
         "description": "Redirect load balancers developer-guide URL",
         "from": "^\\/docs\\/cloud-load-balancers\\/v1\\/developer-guide\\/(.*?)",
         "to": "/docs/cloud-load-balancers/v1/$1",
         "rewrite": false,
         "status": 301
     },
    

  • Use a json linter to verify that the JSON syntax is correct.

• Commit the changes, and push to your fork.
• Submit your updates as a PR against the upstream repository. Include a link to the PR containing the refactored documentation source.
• After the PR is merged, verify that the content is deployed to the new URL, for example https:\\developer.rackspace.com\docs\<updated-path>
• Verify that the redirect rule is working by clicking the Developer Guide link on the DRC docs landing page.

Note: Nexus-control changes take longer to deploy than content changes. You can check the nexus-control version information to determine whether the commit has been deployed.

Update the documentation landing page

Update the menu so that it matches the Load Balancers v1 example shown in the following figure:

Important: Don't commit the landing page updates until you have verified that the content has been deployed to the new URL.

Some menus might be slightly different if the product doesn't have an SDK Quickstart, or if it has additional documentation. If you have questions about the menu content or order, open an issue.

• Fork and clone the docs-quickstart repo to your local system.
• Find the menu for the API documentation you are updating.
• Update the title list and href link targets with the information for your documentation.
• Save the file.
• Commit the changes and push to your fork.
• Submit your updates as a PR against the upstream repository. Include a link to the PR containing the refactored documentation source.
  • Check the PR builder preview to make sure the landing page renders correctly with your updates.
  • Request someone to review and merge the PR.

The auth link in the service endpoints topic should link up to the GSG auth section; this topic currently links to the Dev guide auth section.

https://developer.rackspace.com/docs/cloud-files/v1/use-cases/public-access-to-your-cloud-files-account/#create-the-tempurl has a Python2 code example.

Since Python2 is EOL after 2020, we recommend a Python3 code example. Not perfect by any means, but as a start:

    method = method.upper()
    base_url, object_path = object_url.split('/v1/')
    object_path = '/v1/' + object_path
    #  print object_url
    hmac_body = '%s\n%s\n%s' % (method, expires, object_path)
    temp_url_key_bytes = bytes(temp_url_key , 'latin-1')
    hmac_body_bytes = bytes(hmac_body, 'latin-1')
    temp_url_sig = hmac.new(temp_url_key_bytes, hmac_body_bytes, sha256).hexdigest()
    s = '{object_url}?temp_url_sig={temp_url_sig}&temp_url_expires={expires}'
    temp_url = s.format(object_url=object_url, temp_url_sig=temp_url_sig, expires=expires)

Update per checklist.

The table titles have moved to below the table instead of on top:

Old:

New:

Note: This is an update from the python package which I cannot change from our application.

The callout boxes (note, important, warning, etc) have little icons that are now overlapping with the text in the box

In reviewing the migration, I noticed a few links to api.rackspace.com. Now's a good time to find an alternative link since that site will be removed/redirected.

Does cloud files support .Net Core 2.0?

See #84.

go back and add in some decent examples.

Some links are starting on a new line, have a different font size, and aren't the hyperlink-blue color. I checked the RST and there can be two links formatted exactly the same and one looks normal inline and the other starts a new line. Not sure what the trigger is

SHA1 is considered cryptographically weak. Cloud Files TempURL supports SHA256 as well, but this isn't mentioned anywhere in the docs.

From email: 3/14/2017
Apologies if I reached the incorrect team. I had a customer that referenced one of our API documentation page that had the older version on where to find the API key:
https://developer.rackspace.com/docs/cloud-files/v1/getting-started/get-credentials-include/

Reference ticket:
https://encore.rackspace.com/ticketing/account/10040922/ticket/170313-dfw-0001270

Since then the API key is now under 'My Profile & Settings'. I've clicked through the first 4 API documentation page and all of the images are referencing the old location so I'm guessing all of the API doc pages will have to be updated.

Cheers,
Angela Boulineau

Hi,

Could you please add license for this project.

Thanks

While reading the documentation, I noticed that although Cloud Files supports RBAC as documented here, this is not mentioned or linked to from the overview page for Permissions. This seems like an important oversight, because in reading just the overview page, the reader might mistakenly believe that RBAC is not supported.

I think you don't need the double back-tick in the "By using DELETE in the API" heading here:

http://staging.developer.rackspace.com/docs-cloud-files/#delete-cdn-enabled-object

From: Rackspace Hosting [email protected]
Date: Thursday, April 28, 2016 at 1:05 PM
To: Andrew Hale [email protected]
Cc: "[email protected]" [email protected]
Subject: Re: Cloudfiles docs curl examples

Thanks Andrew. I can certainly add a note that they don't work. Do you know if it applies to all curl examples in the cf API docs or a specific set of them?

Do you have any idea if we can get them to work with Windows?

Can you point me to the note that you saw?

I will open an issue in the repo and will send you a link to it.

Thank you! ( I think :-) )

Catherine

Sent from my iPhone - typos may not be my own

On Apr 28, 2016, at 12:51 PM, Andrew Hale [email protected] wrote:

Hi Catherine,

Just seen a report that the example auth curl commands in the docs don’t work under Windows. I’m not sure if this is something we want to note somewhere or…

Cheers,

Andrew

[18:33:31] can anyone confirm that the cURL call to the Rackspace Identity API is correct on this page. https://developer.rackspace.com/docs/cloud-files/v1/developer-guide/
[18:39:02] yeah that works for me geggleto , substituting the username and apikey values for eal ones
[18:39:14] hmmm
[18:39:22] I am getting a bade request body
[18:39:27] but the JSON body is valid
[18:39:42] {"badRequest":{"code":400,"message":"Invalid json request body"}}
[18:39:59] curl https://identity.api.rackspacecloud.com/v2.0/tokens -X POST -d '{"auth":{"RAX-KSKEY:apiKeyCredentials":{"username":"aaa","apiKey":"aaa"}}}' -H "Content-type: application/json"
[18:40:45] yeah im just doing
[18:40:46] curl https://identity.api.rackspacecloud.com/v2.0/tokens -X POST -d '{"auth":{"RAX-KSKEY:apiKeyCredentials":{"username":"ahale","apiKey":"blabla"}}}' -H "Content-type: application/json"
[18:41:53] idk, double check your " and ' are really those chars ?
[18:44:11] .... ok
[18:44:14] works on linux
[18:44:18] does not work on windows
[18:44:20] what the hell
[18:44:22] oO
[18:44:50] literally copied and pasted what i had in my terminal into putty
[18:44:51] lol
[18:46:53] windows isn't sending 10 bytes ;
[18:49:02] loading it from a file fixed it. thanks ahale
[18:49:26] ah cool - no worries, didn't really do much :)
[18:49:42] thanks for report and kindafix though - gonna let our docs team know

Refactor API Guide: QE checklist

Use the following checklist to verify that API guide refactoring for each service. If you have questions, open a docs-common issue.

Do the QE check against the PR submitted to the master repo. Ask the person who did the refactoring to make you a collaborator on their fork in case you want to submit a PR to correct something.

When you build the refactored Sphinx project, use the make clean html command to build chunked content.

• Review the Strider build log for errors. Notify author about any issues.
• Check for broken links.
• Verify that navigation matches the API Guide template.
• Check the API reference section to verify that the methods for each resource are in a single topic.
• Check the General API information topics to make sure they match the common content where possible.
• Check the Authentication topic in the Getting started section to make sure it matches the common template.
• Check conf.py to make sure it has the updates from the
  template.
• Verify that you can build locally from source.

Looking at output on both Chrome and Firefox, there's a spacing problem with the table cells that have headers that have to be wrapped within a cell.

Output:
http://staging.developer.rackspace.com/docs-cloud-files/#cors-headers-for-objects
shows Access-Control-Allo w-Origin.

Source:
https://github.com/rackerlabs/docs-cloud-files/blob/6008034ccc9fa8d38d6477a431821c9e84a0c97d/rst/dev-guide/public-access-to-your-cloud-files-account/cors.rst

If a user tries to copy/paste that header the space will come with it. Let's try to remove that space if possible. For example:

+-----------------------+----------------------------------------------------+
| ``Access-Control-Allo | Specifies the origins that are allowed to make     |
| w-Origin``            | cross-origin requests, separated by a space when   |
|                       | there are multiple values.                         |
+-----------------------+----------------------------------------------------+

should be revised to:

+-------------------------+---------------------------------------------------+
| ``Access-Control-Allow-  | Specifies the origins that are allowed to make   |
| Origin``                 | cross-origin requests, separated by a space when |
|                          | there are multiple values.                       |
+--------------------------+--------------------------------------------------+

The documentation for Create or Update Object Metadata mentions the prefix X-Remove-Object-Meta-. The description of this prefix is misleading.

The POST command to set metadata clears all metadata which is not explicitly set in the request. Headers with the prefix X-Remove-Object-Meta- do not change this behavior, whether or not a value is assigned for the header. The description of X-Remove-Object-Meta- could be completely removed from the document, leading the user to the more accurate alert which appears later on the page.

We need to add a page that has know apps, plugins, extensions, etc.

Looking at https://github.com/rackerlabs/docs-cloud-files/blob/6008034ccc9fa8d38d6477a431821c9e84a0c97d/rst/dev-guide/storage-api-operations/methods/get-show-container-details-and-list-objects-v1-account-container.rst
and
https://github.com/rackerlabs/docs-cloud-files/blob/7569ab3271866919fbfbce02d38ddb10c611b955/src/wadl/rax-cloudFiles-api-v1-rst.wadl

and http://staging.developer.rackspace.com/docs-cloud-files/#show-container-details-and-list-objects

I see that the WADL has for example reddelicious on a line by itself, but then the RST example does not have the correct hard return under "Controlling a Large List of Objects" so you'll probably need to figure out the formatting problem there (or fix it in the RST).

A customer reported that this example does not work, could you test it? Perhaps they took it out of context but as it was reported, I want to make sure we test.

curl -i -X PUT $API_ENDPOINT/v1/$TENANT_ID/yourContainerName/yourObjectName
-H "X-Auth-Token: $AUTH_TOKEN"
-H "Content-Type: image/jpeg"
-H "Content-Length: 0"

Link: https://developer.rackspace.com/docs/cloud-files/v1/developer-guide/#uploading-an-object

Consistent with swift#1354312, we don't document allowed_headers, and the impact that has on API behavior.

get-get-object-content-and-metadata-v1-account-container-object.rst, for example, only describes headers that have semantic relevance to (rack)swift, but doesn't describe the relationship between request headers, allowed headers, and the headers that get returned in an object response.

What would be the best way to organize this?

#84 has a reference to this from @dpgoetz comment:

just scanning over it there is a problem here: https://github.com/rackerlabs/docs-cloud-files/blob/5451cce9e2c623015c701ac676153966608ef0ca/api-docs/use-cases/additional-storage/creating-large-objects.rst#deleting-a-large-object too. i don't have time to fix this right now so i guess we can make a Jira for this for one of the dev to look over? or just keep this issue open? or any pull requests will also be reviewed :)

Currently the heading says "Send requests to the API" should say "Send API requests"