---
name: "_up_method"
area: "API"
kind: "Cookie"
parent: "up.protocol module"
url: "https://unpoly.com/api/_up_method"
---
<nav aria-label="Unpoly docs">[All docs](https://unpoly.com/index.md) · [up.protocol module](https://unpoly.com/api/up.protocol.md)</nav>

# _up_method

The server may set this optional cookie to echo the HTTP method of the initial request.

When the initial page was loaded with a method other than `GET`, set a cookie with that method:

```http
Set-Cookie: _up_method=POST
```

The **simplest implementation** is to set this cookie for every request that is neither `GET` nor an [Unpoly request](https://unpoly.com/api/X-Up-Version.md). For all other requests an existing `_up_method` cookie should be deleted.

When Unpoly boots it will look for this cookie and configure itself accordingly. The cookie is then deleted in order to not affect following requests.

If the initial page was loaded with a non-`GET` HTTP method, Unpoly prefers to make a full page load when you try to update a fragment. Once the next page was loaded with a `GET` method, Unpoly will again update fragments. This fixes two edge cases:

1. Unpoly replaces the initial page state so it can later restore it when the user goes back to that initial URL. However, if the initial request was a POST, Unpoly will wrongly assume that it can restore the state by reloading with GET.
2. Some browsers have a bug where the initial request method is used for all subsequently pushed states. That means if the user reloads the page on a later GET state, the browser will wrongly attempt a POST request. This issue affected Safari 9-12.