Next.js: `asPath` is omitted in getServerSideProps' parameters and `req.url` is inconsistent regarding query parameters

[jgpacker]

The new function getServerSideProps does not have the parameter asPath that getInitialProps has.
I tried using req.url instead, but the query parameters are not consistent.
They are not sent during CSR calls, while they are present during SSR calls.

I would prefer to have the whole URL (like asPath) to analyze the URL using a separate module.
Or have the querystring parameters in req.url

How to reproduce

import React from 'react';
import Router from 'next/router';
import { NextPage, GetServerSideProps } from "next";

const changeUrl = () => Router.push('/test?a=2');


const Test: NextPage = (): JSX.Element => {
  return (<>
    <a onClick={changeUrl}>Click me</a>
  </>);
}

export const getServerSideProps: GetServerSideProps = async ({ req, query, params })  => {
  console.log('req.url', req.url)
  console.log('query', JSON.stringify(query))
  console.log('params', JSON.stringify(params))
  return { props: {} };
}

export default Test;

When accessing http://localhost:3002/test, we get the following output:

req.url /test
query {}
params undefined

When clicking the link, we get the following output:

req.url /test
query {"a":"2"}
params undefined

When accessing http://localhost:3002/test?a=2 with SSR, we get the following output:

req.url /test?a=2
query {"a":"2"}
params undefined

System information

• Version of Next.js: 9.3.1

[jgpacker]

@Timer I added the "How to reproduce" section now

[kbtganesh]

@Timer, I face the same problem with "getServerSideProps" but only when I export the pages statically (npm run export). I can able to run npm run start successfully. Not sure what's the issue with getServerSideProps. Is it fixed?

[homburg]

Relevant line (master ATOW), setting req.url for CSR/data requests for getServerSideProps (without query part): https://github.com/zeit/next.js/blob/ee0081356d7ea166dfed4765f134730c11ecaecf/packages/next/next-server/server/next-server.ts#L434

[danlutz]

I also noticed that ctx.queryin getServerSideProps has incorrect values on client-side navigation, with the following setup:

Folder Structure

/pages/[locale]/p/[slug].tsx

SSR

When accessing "/de-DE/p/some-product-slugs" using SSR, ctx.query.locale has the correct value of "de-DE"

Client-side navigation

When accessing "/de-DE/p/some-product-slugs" using client-side navigation, ctx.query.locale has the incorrect value of "_next"

I think these issues are related, that's why i added it here. We are reverting back to getInitialProps until this is resolved.

[dennisroethig]

Any updates on this? Looks like it got pushed back?

[endrureza]

this becomes a problem for me too. is this fixable or not ?

[ijjk]

Hi, on the latest version of Next.js the request URL is passed through so for a client transition it will be the data URL including any query values e.g. /_next/data/BUILD_ID/PAGE_NAME.json?a=b. The asPath value from getInitialProps is the same as the request URL so this is not passed to getServerSideProps as it shouldn't be needed. What would the case be for wanting asPath to be passed still?

I'm going to close this since it doesn't appear to be a bug after discussing. If after upgrading to the latest version you are still seeing behavior that appears to be incorrect please provide additional details and we can investigate further.

[ratheo]

I still think that it's a bug that req.url assumes two completely different values depending on whether it's a server side or client side transition. Even though the data URL in req.url is the actual request url, the value is an implementation detail, and not what you would expect as a user. Ideally getServerSideProps should expose a router object with the same props as the useRouter hook, so that it would be possible to share logic between code executed in getServerSideProps and React.

[endrureza]

well, the problem is not the asPath doesn't exist on getServerSideProps. i know the value of asPath is equals to url.req on serverside. if i open a path for example http://localhost:3000/blog/whatcha-gonna-do, getInitialProps will return the same blog/whatcha-gonna-do on asPath variable either it's client or server side. Meanwhile, if i use getServerSideProps, i will not get blog/whatcha-gonna-do on client side. so, do you have a solution to this problem ? @ijjk

[jgpacker]

@ijjk This issue may seem confusing right now because req.url behaved differently with getServerSideProps in the past.
Check the console output in the "How to reproduce" section to see how req.url behaved more like asPath in getInitialProps.

The current behavior of req.url in getServerSideProps seems correct, so I agree the bug is solved.

But there was a mix of bug report with feature request in this issue.
Should we create a new issue for this feature request? What do you think?

To make it clear, the feature request would be: Add a parameter similar to asPath in getServerSideProps, which would contain the URL path the user will see in it's browser.

The use cases for this parameter would be things like logging and dynamic path analysis.

[ijjk]

@jgpacker a new feature request for adding a massaged asPath param to getServerSideProps does sound like it would be good to open since it's separate from the initial described issue 👍

[jgpacker]

@endrureza @ratheo I created #16407. Please complement with your use cases