Abstract This document defines two new HTTP headers "Content-Profile" and "Accept-Profile" that enable User Agents and hosts to indicate and negotiate the profile used for representing a specific resource. In this context, a profile is a description of the structural and/or semantic constraints of a group of documents in addition to the syntactical interpretation provided by more generic MIME types. Examples of profiles include Dublin Core Application Profiles, XML Schemata, and RDF Shape Expressions. This document further defines and registers the "profile" parameter for the HTTP "Link" header and suggests a best practice for the use of the new headers together with the "Link" header for the purposes of performing content negotiation and pointing clients to alternate representations.

logout

This specification defines two formats and respective media types for representing sets of links as stand-alone documents. One format is JSON-based, the other aligned with the format for representing links in the HTTP "Link" header field. This specification also introduces a link relation type to support discovery of sets of links.

GET links/resource1 HTTP/1.1
Host: example.org
Accept: application/linkset+json

HTTP/1.1 200 OK
Date: Mon, 12 Aug 2019 10:46:22 GMT
Server: Apache-Coyote/1.1
Content-Type: application/linkset+json
Link: <https://example.org/links/resource1>
      ; rel="alternate"
      ; type="application/linkset"
Content-Length: 1349

{ "linkset":
  [
    { "anchor": "https://example.org/resource1",
      "author": [
        { "href": "https://authors.example.net/johndoe",
          "type": "application/rdf+xml"
        }
      ],
      "memento": [
        { "href": "https://example.org/resource1?version=1",
          "type": "text/html",
          "datetime": "Thu, 13 Jun 2019 09:34:33 GMT"
        },
        { "href": "https://example.org/resource1?version=2",
          "type": "text/html",
          "datetime": "Sun, 21 Jul 2019 12:22:04 GMT"
        }
      ],
      "latest-version": [
        { "href": "https://example.org/resource1?version=3",
          "type": "text/html"
        }
      ]
    },
    { "anchor": "https://example.org/resource1?version=3",
      "predecessor-version": [
        { "href": "https://example.org/resource1?version=2",
          "type": "text/html"
        }
      ]
    },
    { "anchor": "https://example.org/resource1?version=2",
      "predecessor-version": [
        { "href": "https://example.org/resource1?version=1",
          "type": "text/html"
        }
      ]
    },
    { "anchor": "https://example.org/resource1#comment=1",
      "author": [
        { "href": "https://authors.example.net/alice"}
      ]
    }
  ]
}

Robust Links provide multiple pathways to revisit a link's original content, even a long time after the link was put in place. This document describes approaches to robustify links in HTML pages. All approaches assume that, when linking to a web resource, a snapshot of the state of that resource is created, for example, in a web archive or a versioning system. When linking, the URI of the resource, the URI of the snapshot, and the datetime of linking are conveyed.

The most obvious time you'd encounter a 401 error, on the other hand, is when you have not logged in at all, or have provided the incorrect password.

As mentioned in the previous article, the 403 error can result when a user has logged in but they don't have sufficient privileges to access the requested resource. For example, a generic user may be attempting to load an 'admin' route.

The server generating a 401 response MUST send a WWW-Authenticate header field (Section 4.1) containing at least one challenge applicable to the target resource.

That comes in the form of the WWW-Authenticate header with the specific authentication scheme to use. For example, in the case of OAuth2, the response should look like the following:

"The basic principle behind REST status code conventions is that a status code must make the client aware of what is going on and what the server expects the client to do next"

You can fulfill this principle by giving answers to the following questions:Is there a problem or not?If there is a problem, on which side is it? On the client or on the server side?If there is a problem, what should the client do?

Now, assume your client attempts to access a resource that it MUST NOT access at all, for example, because it belongs to another user. What status code should your API return? Should it return a 403 or a 401 status code?You may be tempted to return a 403 status code anyway. But, actually, you can't suggest any missing permission because that client has no way to access that resource. So, the 403 status code gives no actual helpful information. You may think that returning a 401 status code makes sense in this case. After all, the resource belongs to another user, so the request should come from a different user.However, since that resource shouldn't be reached by the current client, the best option is to hide it.

Let's explore a different case now. Assume, for example, that your client sends a request to modify a document and provides a valid access token to the API. However, that token doesn't include or imply any permission or scope that allows the client to perform the desired action.In this case, your API should respond with a 403 Forbidden status code. With this status code, your API tells the client that the credentials it provided (e.g., the access token) are valid, but it needs appropriate privileges to perform the requested action.

The difference is what the server expects the client to do next.

Authentication by schemes outside of RFC2617 is not supported in HTTP status codes and are not considered when deciding whether to use 401 or 403.

Meaning if you have your own roll-your-own login process and never use HTTP Authentication, 403 is always the proper response and 401 should never be used.

If HTTP authentication is not in use and the service has a cookie-based authentication scheme as is the norm nowadays, then a 403 or a 404 should be returned.

While this seems to me like it's probably an accurate interpretation of the old RFC 2616, note that RFC 7231 defines the semantics of a 403 differently, and in fact explicitly states that "The client MAY repeat the request with new or different credentials."

it depends on the application but generally, if an authenticated user doesn't have sufficient rights on a resource, you might want to provide a way to change credentials or send a 401.

FORBIDDEN: Status code (403) indicating the server understood the request but refused to fulfill it. User/agent known by the server but has insufficient credentials. Repeating request will not work, unless credentials changed, which is very unlikely in a short time span.

Send a 302 to your login-page

The statement is "If the request already included Authorization credentials". That means if this is a response from a request which provided the credential (e.g. the response from a RFC2617 Authentication attempt). It is essentially to allow the server to say, "Bad account/password pair, try again". In the posed question, the user is presumably authenticated but not authorized. 401 is never the appropriate response for those circumstances.

This may be because it is known that no level of authentication is sufficient (for instance because of an IP blacklist), but it may be because the user is already authenticated and does not have authority.

401 is only appropriate for HTTP Authentication

I'm using both - the 401 for unauthenticated users, the 403 for authenticated users with insufficient permissions.

From your use case, it appears that the user is not authenticated. I would return 401.

There's a problem with 401 Unauthorized, the HTTP status code for authentication errors. And that’s just it: it’s for authentication, not authorization. Receiving a 401 response is the server telling you, “you aren’t authenticated–either not authenticated at all or authenticated incorrectly–but please reauthenticate and try again.” To help you out, it will always include a WWW-Authenticate header that describes how to authenticate.

So, for authorization I use the 403 Forbidden response. It’s permanent, it’s tied to my application logic, and it’s a more concrete response than a 401. Receiving a 403 response is the server telling you, “I’m sorry. I know who you are–I believe who you say you are–but you just don’t have permission to access this resource. Maybe if you ask the system administrator nicely, you’ll get permission. But please don’t bother me again until your predicament changes.”

401 'Unauthorized' should be 401 'Unauthenticated', problem solved !

UNAUTHORIZED: Status code (401) indicating that the request requires authentication, usually this means user needs to be logged-in (session). User/agent unknown by the server. Can repeat with other credentials. NOTE: This is confusing as this should have been named 'unauthenticated' instead of 'unauthorized'.

Checks are usually done in this order: 404 if resource is public and does not exist or 3xx redirection OTHERWISE: 401 if not logged-in or session expired 403 if user does not have permission to access resource (file, json, ...) 404 if resource does not exist or not willing to reveal anything, or 3xx redirection

+----------------------- | RESOURCE EXISTS ? (if private it is often checked AFTER auth check) +----------------------- | | NO | v YES v +----------------------- 404 | IS LOGGED-IN ? (authenticated, aka user session) or +----------------------- 401 | | 403 NO | | YES 3xx v v 401 +----------------------- (404 no reveal) | CAN ACCESS RESOURCE ? (permission, authorized, ...) or +----------------------- redirect | | to login NO | | YES | | v v 403 OK 200, redirect, ... (or 404: no reveal) (or 404: resource does not exist if private) (or 3xx: redirection)

I would expect that 401 to be named "Unauthenticated" and 403 to be named "Unauthorized". It is very confusing that 401, which has to do with Authentication,

The server generating a 401 response MUST send a WWW-Authenticate header field (Section 4.1) containing at least one challenge applicable to the target resource.

If the ticket is incorrect or damaged, you cannot even go through the airport security: when they check your ticket, it will be refused. You are Forbidden to enter the boarding area of the airport.

These two sound pretty similar to me. And to make things even more confusing, 403 “Forbidden” says that the server refuses to “authorize” the request but it’s code 401 that is called “Unauthorized”. 😵

Indicates that though the request was valid, the server refuses to respond to it. Unlike the 401 status code, providing authentication will not change the outcome.

If authentication credentials were provided in the request, the server considers them insufficient to grant access.

401 Unauthorized The requestor is not authorized to access the resource. This is similar to 402 but is used in cases where authentication is expected but has failed or has not been provided.

403 :forbidden

401 :unauthorized

You’d like to access the content of the resource but you’re not logged in (so not authenticated yet). The server will return you a 401 error. You need to log in to be able to access the resource.

You’d like to delete the user, but you’re authenticated as a regular user, not as an admin. The server doesn’t allow regular users to perform such requests, so in the result, the server will send you a 403 error. Re-authentication won’t make any difference.

Relationship to TCP and HTTP _This section is non-normative._ The WebSocket Protocol is an independent TCP-based protocol. Its only relationship to HTTP is that its handshake is interpreted by HTTP servers as an Upgrade request. By default, the WebSocket Protocol uses port 80 for regular WebSocket connections and port 443 for WebSocket connections tunneled over Transport Layer Security (TLS) [RFC2818].

The difference between PUT and POST is that PUT is idempotent: calling it once or several times successively has the same effect (that is no side effect), whereas successive identical POST requests may have additional effects, akin to placing an order several times.

> I should have used "side-effect-free" instead of "idempotent" in my tweetsThe HTTP term is "safe method".

Sending body/payload in a GET request may cause some existing implementations to reject the request — while not prohibited by the specification, the semantics are undefined. It is better to just avoid sending payloads in GET requests.

Requests using GET should only be used to request data (they shouldn't include data).

So long as the filters are only using GET requests to pull down links, there’s nothing fundamentally wrong with them. It’s a basic (though oft-ignored) tenet of web development that GET requests should be idempotent; that is, they shouldn’t somehow change anything important on the server. That’s what POST is for. A lot of people ignore this for convenience’s sake, but this is just one way that you can get bitten. Anyone remember the Google Web Accelerator that came out a while ago, then promptly disappeared? It’d pre-fetch links on a page to speed up things if you clicked them later on. And if one of those links happened to delete something from a blog, or log you out… well, then you begin to see why GET shouldn’t change things. So yes, the perfect solution to this is a 2-step unsubscribe link: the first step takes to you a page with a form on it, and that form then POSTs something back that finalizes the unsubscribe request.

Idempotent just means that following a link twice has exactly the same effect on persistent state as clicking it once. It does not mean that following the link must not change state, just that after following it once, following it again must not change state further. There are good reasons to avoid GET requests for changing state, but that’s not what idempotent means.

Arguably any link that performs such an action via GET is fundamentally broken. A proper unsubscribe should direct to a page with a form that requires a POST submission. (Of course, in the real world, few things are proper.)

This is not advice. A GET is defined in this way in the HTTP protocol. It is supposed to be idempotent and safe.

An HTTP method is safe if it doesn't alter the state of the server. In other words, a method is safe if it leads to a read-only operation.

All safe methods are also idempotent, but not all idempotent methods are safe. For example, PUT and DELETE are both idempotent but unsafe.

Each of them implements a different semantic, but some common features are shared by a group of them: e.g. a request method can be safe, idempotent, or cacheable.

request method can be safe, idempotent, or cacheable.

I don't like that I can't really use head? to know it's a HEAD request, but I (think I) understand the reasoning

And now let’s be even bolder still. What if every country in the world chose to be like Costa Rica in prioritizing human well-being, using its wealth for the well-being of its citizens?

Handling 401s well is important for the user's experience. They won't happen often (though more often than I expected), but really do break everything if you're not careful. Getting a good authentication abstraction library for Vue or Ember or whatever you are using should help with a lot of the boring parts. You'll probably need to define some extra strategies/rules for this cookie session approach, but if it's anything like in ember-simple-auth they're so simple it feels like cheating, because the Rails app is doing all of the hard work and you just need the js part to spot a 401 and handle logging in and retrying whatever it was doing before.

This status is sent with a WWW-Authenticate header that contains information on how to authorize correctly.

The HTTP 401 Unauthorized client error status response code indicates that the request has not been applied because it lacks valid authentication credentials for the target resource.

Similar to 403 Forbidden, but specifically for use when authentication is required and has failed or has not yet been provided. The response must include a WWW-Authenticate header field containing a challenge applicable to the requested resource.

The job of this function is to return a { status, headers, body } object representing the response, where status is an HTTP status code: 2xx — successful response (default is 200) 3xx — redirection (should be accompanied by a location header) 4xx — client error 5xx — server error

facebook.com/CienciaUNAM.MX

op irrigation and drainage, multiple outdoor decks and terraces spanning more than 2,000 square feet, and a pool with a spa, according to the listing with Benjamin Illulian of Keller Williams. More: Jeff Bezos Drops $16 Million on Another Manhattan Pad to Create a ‘Vertical’ Dream Home Interior space is divided into four bedrooms, four bathrooms, formal living and dining rooms and an eat-in kitchen. The property is equipped with smart home appliances, and comes with 50 feet of curb frontage. Plus, it’s just steps away from popular shops and restaurants, the listing said. Mr. Illulian, who listed the property for $5.195 million in December 2019, didn’t respond to a request for comment. From: Penta Art Museums Given Leeway in Funding Mr. Legend, 41, a singer and music producer, and Ms. Teigen, 34, a model and TV personality, could not immediately be reached for comment. The couple recently purchased a Manhattan apartment—their second in the same building. Marshall Peck of Douglas Elliman, who represented the buyers in the deal, declined to comment.   if (!window.WEBUI_NEWSLETTERCARDS) { window.WEBUI_NEWSLETTERCARDS = []; } window.WEBUI_NEWSLETTERCARDS.push({ articleId: 'MG0000214176', state: {"data":{},"id":"mg/newsletterCard","context":{"newsletterId":"801","newsletter":{"_id":"5ec24a31d782d55d025c60ae","node_type":"newsletter","edition":"mansionglobal","section":"newsletters","id":"801","label":"Week in Review","description":"Shares the stories you may have missed from the world of luxury real estate","index":2,"previewURL":"","imageURL":"","addURL":"","addLabel":"","subOnly":false,"orderAlphabetic":"","options":"","disableSignup":false},"isLoggedIn":false,"hasFullNewsletterAccess":false,"hasFreeNewsletterAccess":false,"region":"na,us","editionId":"mansionglobal","returnLink":"https://www.mansionglobal.com"},"package":{"accessedContext":[],"nodes":{"0":{"component":{"id":"275181c7-8620-4df3-a008-d0cd9937db22","acceptsTypes":{},"isConditional":false,"$context":{},"decorators":["MGTheme"]},"children":["webUINewsletterCard-0.0"],"treeOrder":1,"name":"0","hierarchy":"0"},"webUINewsletterCard-0.0":{"component":{"content":{},"options":{"productId":200,"captchaSiteKey":"6LcmI7sUAAAAAF-vTKb3JIwIzz2CXCx8hJW0Ukis","origin":"articles_app","returnLink":"https://www.mansionglobal.com","editionId":"mansionglobal","content":{"data":{}}},"decorators":["MGTheme"],"id":"c7081dd6-0394-e7b2-1124-a02c2970agdf","acceptsTypes":{"newsletter_config_data":true},"isConditional":false,"$context":{"./content/newsletter":{"key":[".","content","newsletter"],"value":["#","newsletter"]},"./options/region":{"key":[".","options","region"],"value":["#","region"]},"./options/newsletterId":{"key":[".","options","newsletterId"],"value":["#","newsletterId"]},"./options/userEmail":{"key":[".","options","userEmail"],"value":["#","userEmail"]},"./options/loggedIn":{"key":[".","options","loggedIn"],"value":["#","isLoggedIn"]},"./options/hasFullNewsletterAccess":{"key":[".","options","hasFullNewsletterAccess"],"value":["#","hasFullNewsletterAccess"]},"./options/hasFreeNewsletterAccess":{"key":[".","options","hasFreeNewsletterAccess"],"value":["#","hasFreeNewsletterAccess"]},"./options/content/data/list":{"key":[".","options","content","data","list"],"value":["#","newsletter"]}}},"name":"webUINewsletterCard-0.0","treeOrder":2,"hierarchy":"0"}},"root":"0","states":{"nodes":[],"data":[],"hierarchy":{},"dedupeGroups":{},"components":{"code___decoratedComponent___275181c7-8620-4df3-a008-d0cd9937db22___MGTheme":{"id":"275181c7-8620-4df3-a008-d0cd9937db22","decorators":["MGTheme"]},"code___decoratedComponent___c7081dd6-0394-e7b2-1124-a02c2970agdf___MGTheme":{"id":"c7081dd6-0394-e7b2-1124-a02c2970agdf","decorators":["MGTheme"]}}},"refreshInterval":null},"currentState":{"data":[],"nodes":{},"hierarchy":{},"dedupeGroups":{},"components":{"code___decoratedComponent___275181c7-8620-4df3-a008-d0cd9937db22___MGTheme":{"id":"275181c7-8620-4df3-a008-d0cd9937db22","decorators":["MGTheme"]},"code___decoratedComponent___c7081dd6-0394-e7b2-1124-a02c2970agdf___MGTheme":{"id":"c7081dd6-0394-e7b2-1124-a02c2970agdf","decorators":["MGTheme"]}}}} }); Newsletter Sign-up Week in Review Shares the stories you may have missed from the world of luxury real estate PREVIEWSUBSCRIBE window.INITIAL_PROPS_NEWSLETTER_BOTTOM_COL = {} NEW LISTINGS SINGLE FAMILY HOME LOS ANGELES

Source maps eliminate the need to serve these separate files. Instead, a special source map file can be read by the browser to help it understand how to unpack your assets. It "maps" the current, modified asset to its "source" so you can view the source when debugging. This way you can serve assets in development in the exact same way as in production.

When Sprockets was introduced, one of the opinions that it held strongly, is that assets such as CSS and JS should be bundled together and served in one file.

The alternative was to have multiple scripts or stylesheet links on one page, which would trigger multiple HTTP requests. Multiple requests mean multiple connection handshakes for each link “hey, I want some data”, “okay, I have the data”, “alright I heard that you have the data, give it to me” (SYN, ACK, SYNACK). Even once the connection is created there is a feature of TCP called TCP slow start that will throttle the speed of the data being sent at the beginning of a request to a slower speed than the end of the request. All of this means transferring one large request is faster than transferring the same data split up into several smaller requests.

GET is the primary mechanism of information retrieval and the focus of almost all performance optimizations.

So before using GET with Body parameter, you must first ensure the servers are supporting it. It is possible that some servers might ignore the body of GET request or behavior like caching GET/HEAD requests might cause issues.

A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request.

All browers handle 302 incorrectly. Chrome 30, IE10. It became the de facto incorrect implementation; that cannot be changed because so many web-sites issue mistakenly issue 302. In fact ASP.net MVC incorrectly issues 302, depending on the fact that browsers handle it incorrectly.

strict-origin: Only send the origin of the document as the referrer when the protocol security level stays the same (e.g. HTTPS→HTTPS), but don't send it to a less secure destination (e.g. HTTPS→HTTP).

10.1038/498255a

115 results found

Datos abiertos enlazados y libros abiertos: impacto en las bibliotecas y en el desarrollo de la sociedad de la información

I don't think it should be the individual application's responsibility to add Cache-Control: Vary when that negotiation/routing is done by Rails on behalf of the app, do you?

Expected behavior Response should include Vary: Accept to show that the response differs due to content negotiation. Actual behavior All responses are considered equal to the user agent, leading to caching issues. See these bugs:

Yeah, so I believe what we want is.. If an action has no templates defined at all, AND it has no respond_to { ... } block, then it should do a 204 If an action has certain templates defined, AND it has no respond_to { ... } block, then it should do a 406 for formats with no templates If an action has a respond_to { ... } block, then it should do a 406 for formats not in the list

“What other framework has integrated support for 786 TRY IT NOW ?”

When it comes to building HTTP APIs, other frameworks weigh you down with tons of dependencies and unnecessary abstractions. Falcon cuts to the chase with a clean design that embraces HTTP and the REST architectural style.