सबसे प्रासंगिक और उल्लेखनीय मुद्दे #1189 और #3876 . हैं

इसके अंत में हल होने की प्रतीक्षा कर रहे हैं! @timneutkens अगले 7 के लिए पिछली स्लैश समस्याओं की स्थिति क्या है?

@NathanielHill मैं इसे next@7 पर पुन: पेश कर सकता हूं

मैं नेक्स्टज 7 का उपयोग कर रहा हूं और पिछला स्लैश देव और ठेस दोनों पर मेरे लिए 404 का उत्पादन कर रहा है:

• प्रारंभिक पृष्ठ लोड पर
• पृष्ठ पर ताज़ा करें

और प्रभावित करता है:

• एक बाहरी लिंक
• एक आंतरिक लिंक
• यूआरएल ब्राउज़र में चिपकाया गया

बस अनुगामी स्लैश को हटाने से समस्या ठीक हो जाती है।

अनुगामी स्लैश अक्सर ब्राउज़र, सर्वर और/या अन्य सेवाओं द्वारा जोड़े जाते हैं जहां लिंक चिपकाए जा सकते हैं, इसलिए जब मैं आंतरिक लिंक को नियंत्रित कर सकता हूं, तो यह नियंत्रित करना कठिन है कि बाहरी उपयोगकर्ता किस लिंक पर आ रहे हैं

मैं इस मुद्दे को संस्करण 7 में भी देख रहा हूं। सुनिश्चित नहीं है कि यह प्रासंगिक है, लेकिन, मैं एक Next.js प्रोजेक्ट को दूसरे नाओ परिनियोजन के सबफ़ोल्डर में अलियासिंग कर रहा हूं। तो हमारा आधार यूआरएल primer.style और हम अपने primer-components.now.sh Next.js ऐप को primer.style/components उपनाम कर रहे हैं। उत्पादन पर, primer.style/components का अनुक्रमणिका पृष्ठ ठीक काम करता है, लेकिन primer.style/components/ 404 उत्पन्न करता है।

मुझे इस मुद्दे को खोजने के लिए थोड़ा सा खोजना पड़ा। मैं Netlify पर स्थिर परिनियोजन का उपयोग करता

मुझे भी यह समस्या हो रही है और यह वास्तव में कष्टप्रद है, मुझे आशा है कि यह जल्द ही ठीक हो जाएगा।

यदि आप पिछला स्लैश चाहते हैं, तो आप बस ऐसा कर सकते हैं। <Link href='/about' as='/about/'><a>about</a></Link> लेकिन यदि आप शुक्रवार/अगले मार्गों का उपयोग कर रहे हैं तो यह संभव नहीं है। तो मेरे पास एक कांटा है जहां आप trailingSlash को प्रोप के रूप में जोड़ सकते हैं। उम्मीद है ये मदद करेगा

यदि आप पिछला स्लैश चाहते हैं, तो आप बस ऐसा कर सकते हैं। <Link href='/about' as='/about/'><a>about</a></Link> लेकिन यदि आप शुक्रवार/अगले मार्गों का उपयोग कर रहे हैं तो यह संभव नहीं है। तो मेरे पास एक कांटा है जहां आप trailingSlash को प्रोप के रूप में जोड़ सकते हैं। उम्मीद है ये मदद करेगा

@aluminick मुझे क्षमा करें, मैंने अभी यह कोशिश की है और यह मेरे लिए काम नहीं करता है। मुझे अभी भी ट्रेलिंग-स्लेश पेज (नवीनतम रिलीज) मिलता है, जो रीफ्रेश (वर्तमान व्यवहार) के बाद नहीं मिलता है।

न तो #6664 और न ही #6752 इनसे मदद करते हैं, क्योंकि experimental.exportTrailingSlash मदद नहीं करता है क्योंकि यह केवल next export , मेरा मानना ​​है कि

@Janpot द्वारा एक आशाजनक पुल अनुरोध #6421 था जो दुर्भाग्य से किसी भी आम सहमति तक नहीं पहुंचा था

@iamstarkov इस मुद्दे की स्थिति क्या है? server.js हुक के अलावा कोई समाधान?

@dryleaf स्थिति: यह अभी भी खुला है

एक समान समस्या... एकाधिक फ़ॉरवर्ड स्लैश जोड़े जाने पर रीडायरेक्ट करें। उदाहरण: https://github.com/zeit/next.js///////////issues/5214

GitHub url अप्रासंगिक हैं

@iamstarkov सुनिश्चित नहीं है कि आपका क्या मतलब है। लेकिन मेरी मूल पोस्ट को दोबारा पढ़ने के बाद, ऐसा लगता है कि मैं और अधिक स्पष्ट हो सकता था।

जब कोई ऐप Next.js के साथ बनाया जाता है, तो url को (अधिमानतः) कैसे काम करना चाहिए, इसका एक सरल प्रदर्शन होने के लिए GitHub url का मतलब है। दूसरे शब्दों में, यदि कोई उपयोगकर्ता अतिरिक्त स्लैश जोड़ता है, तो यूआरएल को अभी भी काम करना चाहिए।

नेक्स्टज 9 के लिए कोई अपडेट?

मैं नेक्स्ट में नया हूं लेकिन आप लोग इस समस्या के लिए क्या उपाय अपना रहे हैं?

@iamstarkov इस मुद्दे की स्थिति क्या है?

मैं हैरान हूं कि करीब एक साल से इस मसले का कोई हल नहीं निकला!
क्या Next.js टीम को इसे ठीक करने के लिए किसी अन्य कारण की आवश्यकता है?

पीछे के स्लैश की परवाह किए बिना URL को काम करना चाहिए। वेब पर किसी भी साइट की जाँच करें।

अगर यह Next.js के दायरे से बाहर है, तो हमें इसे अभी में कॉन्फ़िगर करने की क्षमता दें।
मैं वास्तव में उलझन में हूं कि Zeit टीम वर्षों से ऐसे महत्वपूर्ण मुद्दों की उपेक्षा करती है।

@exentrich यह

now.json :

"routes": [
    {
      "src": "/(.*)/",
      "status": 301,
      "headers": { "Location": "/$1" }
    },
    ...
]

हालांकि, मुझे यह भी समझ में नहीं आता कि इसे नेक्स्ट.जेएस द्वारा ही क्यों नहीं संभाला जाता है और टीम ने इस मुद्दे को क्यों नजरअंदाज कर दिया है।

यह, public/ (कार्यों में) के साथ मुख्य मुद्दे हैं जो मुझे सीआरए में परिवर्तित होते दिखाई दे रहे हैं।

@rauchg

@ नथानिएलहिल धन्यवाद!
मैंने इस समाधान की कोशिश की, लेकिन क्वेरी पैरामीटर हटा दिए गए हैं। उदाहरण के लिए /some/?query=1 /some बिना किसी प्रश्न के

हाँ, यह एक समस्या की तरह लगता है @exentrich

मैंने उस व्यवहार का अनुमान नहीं लगाया होगा जैसा कि मुझे बताया गया है कि एक निहित ^ और $ रेगेक्स के चारों ओर लपेटा गया है (जिसका अर्थ है कि आपका उदाहरण मेल नहीं खाएगा)। हो सकता है कि इसे वापस जोड़ने के लिए क्वेरी स्ट्रिंग तक पहुंचने का कोई तरीका हो: man_shrugging: शुभकामनाएं

एक कस्टम एक्सप्रेस सर्वर और avinoamr/कनेक्ट-स्लैश का उपयोग करके इसे काम करने की कोशिश कर रहा है लेकिन ऐसा लगता है कि एक ही समस्या में चल रहा है

यह निश्चित रूप से एक बड़ा मुद्दा है क्योंकि विशेष रूप से / मार्ग त्रुटि पृष्ठ फेंकते हैं और इससे एसईओ को नुकसान होता है (जो कि अगला के प्राथमिक ड्रॉ में से एक है)।

301 रीडायरेक्ट और कस्टम एक्सप्रेस सर्वर सभी ठीक करने के बजाय हैक होने लगते हैं। मेरे मामले में, मेरे पास बिना किसी कस्टम एक्सप्रेस सर्वर के नेक्स्ट पर बनाया गया एक पूर्ण कामकाजी एप्लिकेशन

पुनश्च: मुझे नेक्स्ट ❤️ . के साथ काम करना बिल्कुल पसंद है

यह निश्चित रूप से एक बड़ा मुद्दा है, खासकर क्योंकि / मार्ग त्रुटि पृष्ठ फेंकते हैं और इससे एसईओ को नुकसान होता है

यह आपके SEO को नुकसान नहीं पहुंचाता है। Google अनुगामी स्लैश को एक भिन्न पृष्ठ के रूप में मानता है। 404 होने से आपकी साइट के किसी भी अन्य गैर-मौजूदा पृष्ठ की तुलना में SEO पर कोई प्रभाव नहीं पड़ता है। इसके अलावा, जब तक आप इसे किसी अनुगामी स्लैश से लिंक नहीं करते हैं, तब तक Google इसे पहले स्थान पर क्रॉल करने का प्रयास नहीं करेगा। यह मुद्दा, जबकि अभी भी एक वैध मुद्दा है, आप सभी की तुलना में कम महत्वपूर्ण है।

@ निक-जॉन @NathanielHill @dkrish @exentrich

301 रीडायरेक्ट करने के लिए आपको एक्सप्रेस सर्वर का उपयोग नहीं करना चाहिए। आपकी आवश्यकताओं पर निर्भर करता है, लेकिन मैं एक कस्टम server.js साथ मेरा पूरा करने में सक्षम हूं।

301 रीडायरेक्ट भी SEO के लिए सबसे अच्छा तरीका है, क्योंकि आपको स्लैश और नॉन-स्लैश रूट के लिए डुप्लिकेट कंटेंट पेनल्टी नहीं मिलेगी।

मुझे ❤️ Next.js पसंद है, लेकिन मैं इस काम के बिना इसे संभालने के लिए वोट देता हूं।

// server.js

const { createServer } = require('http');
const { parse } = require("url");
const next = require("next");

const dev = process.env.NODE_ENV !== 'production'
const port = parseInt(process.env.PORT, 10) || 3000;
const app = next({ dev, quiet: false });
const handle = app.getRequestHandler();

(async () => {
    await app.prepare();
    const server = createServer();

    server.on('request', async (req, res) => {

        const parsedUrl = parse(req.url, true);
        const { pathname, query } = parsedUrl;

        if (pathname.length > 1 && pathname.slice(-1) === "/") {
            console.log('server.js - redirect on "/"...', pathname, query);
            const queryString = await Object.keys(query).map(key => key + '=' + query[key]).join('&');
            res.writeHead(301, { Location: pathname.slice(0, -1) + (queryString ? '?'+ queryString : '') });
            res.end();
        }

        handle(req, res, parsedUrl);

    });

    await server.listen(port);
    console.log(`🚀 Ready on http://localhost:${port}`);

})();

@ जनपोट

यह आपके SEO को नुकसान नहीं पहुंचाता है। Google अनुगामी स्लैश को एक भिन्न पृष्ठ के रूप में मानता है। 404 होने से आपकी साइट के किसी भी अन्य गैर-मौजूदा पृष्ठ की तुलना में SEO पर कोई प्रभाव नहीं पड़ता है।

मैं आपकी बात लेता हूं कि यह विशेष रूप से एसईओ को सहज रूप से चोट नहीं पहुंचाता है। लेकिन यह डेवलपर्स पर हर बार URL परिभाषाओं को सही करने के लिए अतिरिक्त दबाव डालता है, जो मानवीय त्रुटियों के अधीन है। एक डेवलपर जो नेक्स्ट में नया है, उसे जरूरी नहीं पता होगा कि निम्नलिखित (पूरी तरह से सामान्य दिखने वाला) यूआरएल 404 पेज पर ले जाएगा। <Link href='/people/'>

एक परिपक्व ढांचा आदर्श रूप से ऐसी मानवीय त्रुटियों के अधीन नहीं होना चाहिए।

इसके अलावा, जब तक आप इसे किसी अनुगामी स्लैश से लिंक नहीं करते हैं, तब तक Google इसे पहले स्थान पर क्रॉल करने का प्रयास नहीं करेगा।

फिर से - वहाँ अकस्मात _ को जोड़ने लोगों के मुद्दे मौजूद www.mysite.com/people/_ _ के बजाय www.mysite.com/people_ (- यहां तक कि सबसे डेवलपर्स जो दोनों के उपयोगकर्ताओं के लिए बिल्कुल वैसा ही होने लगते हैं)।

ये दोनों परिदृश्य _can_ SEO को प्रभावित करते हैं।

अब, SEO प्रभाव पर विचार न करते हुए, URL का अर्थपूर्ण अर्थ भी है - _does_ _ www.mysite.com/people / _ किस ओर इशारा करता है? आदर्श रूप से क्योंकि यह एक निर्देशिका की ओर इशारा कर रहा है, अगला pages > people > index.js में जो कुछ भी है उसे वापस करना चाहिए (जैसा कि _www.mysite.com/people_ के लिए pages > people.js के विपरीत) लेकिन इसके बजाय यह कुछ भी नहीं देता है, जो कि एक बहुत ही है रूटिंग कैसे काम करता है में उच्च स्तरीय दोष।

प्रमुख रूटिंग लाइब्रेरी में इसके लिए पहले से ही कुछ प्रावधान हैं - जैसे रिएक्ट राउटर के मामले में isExact

जबकि मैं समझता हूं कि आप कहां से आ रहे हैं, मुझे अभी भी लगता है कि यह एक ज्वलंत मुद्दा है जिसे आगे बढ़ाने की जरूरत है

next export . के मामले में भी यह पूरी तरह से अपरिहार्य है

लोगों के गलती से लिंक होने की समस्या मौजूद है...

मौजूद है गलती से किसी भी गैर मौजूदा यूआरएल को जोड़ने लोगों का मुद्दा क्यों करेंगे /some/path/ हो कम गैर मौजूदा की तुलना में /some/path/dhgfiuwo ?

यूआरएल का अर्थपूर्ण अर्थ भी है

यह अत्यधिक व्यक्तिपरक है, जहाँ तक मुझे पता है कि वहाँ कोई कल्पना नहीं है जो यह निर्धारित करती है कि शब्दार्थ अंतर क्या है। यूआरएल स्पेक के मुताबिक, पिछली स्लैश के साथ और बिना अलग यूआरएल माना जाता है। मैं कम से कम 7 अलग-अलग मान्य व्यवहारों के बारे में सोच सकता हूं:

• पूरी तरह से अलग सामग्री के साथ और उसके बिना
• 404 के साथ, बिना संकल्प के
• संकल्प के साथ, बिना 404
• बिना रीडायरेक्ट के साथ
• के साथ रीडायरेक्ट किए बिना
• विहित संकेत के साथ साथ और बिना समान सामग्री है with
• विहित संकेत के साथ और बिना समान सामग्री के साथ और बिना

इसे /pages/some-page.js और /pages/some-page/index.js (या दोनों) होने की संभावना के साथ जोड़ें।

क्या next.js उन सभी उपयोग के मामलों का समर्थन करना चाहिए? क्या इसे एक डिफ़ॉल्ट व्यवहार चुनना चाहिए?

मैं इसके खिलाफ नहीं हूं, लेकिन इसे पहले लागू करने की कोशिश करने के बाद, मुझे लगता है कि शुरुआत में जितना लगता है उससे कहीं अधिक बारीकियां हैं।

किसी भी गैर-मौजूदा यूआरएल से गलती से लोगों के लिंक होने का मुद्दा मौजूद है, क्यों/कुछ/पथ//कुछ/पथ/dhgfiuwo से कम गैर-मौजूद होगा?

मामले के लिए /some/path/dhgfiuwo - लोग उम्मीद करते हैं कि dhgfiuwo मार्ग गायब हो सकता है। (उदाहरण के लिए, उपयोगकर्ता dhgfiuwo सिस्टम में नहीं मिल सकता है और users/dhgfiuwo गलत है। सिस्टम में उपयोगकर्ता की अनुपस्थिति एक अपेक्षित घटना है।)
/some/path/ के मामले में - लोग उम्मीद करते हैं कि यह पथ /some/path जैसा ही होगा, क्योंकि यह अन्य साइटों पर डिफ़ॉल्ट व्यवहार है।
इसलिए, में एक विफलता would/some/path/ कम गैर मौजूदा है की तुलना में /some/path/dhgfiuwo ।

मैं देख रहा हूं कि दूसरों ने अपने समाधान पोस्ट किए हैं, इसलिए मैं अपना दृष्टिकोण साझा करना चाहता हूं: https://github.com/DevSpeak/next-trailingslash

डायनेमिक रूटेड पेजों के लिए कुछ सुधार और समर्थन जब ?= की बात आती है तो आईएमओ किया जाना चाहिए, लेकिन यह केवल विचार दिखाने के लिए है।

एक त्वरित समाधान के लिए, आप डिफ़ॉल्ट _error पृष्ठ को बदल सकते हैं (जैसा कि @DevSpeak के उदाहरण में है)।

@DevSpeak , मैं आपके रेपो के लिए कुछ बदलावों की अनुशंसा करता हूं:

• 301 रीडायरेक्ट से बचें - वे ब्राउज़र द्वारा स्थायी रूप से कैश किए जाते हैं , और इससे आपको बहुत दर्द हो सकता है। ज्यादातर मामलों में, आपको केवल 302 की आवश्यकता होती है।
• आपकी त्रुटि कोड टर्नरी को अपडेट किया जा सकता है (यह पिछले सप्ताह तक दस्तावेज़ों में पुराना था)
• यह केवल सर्वर-साइड है, इसलिए आप इसे क्लाइंट बंडल से ट्री-शेक करने के लिए if (typeof window === 'undefined') { ... } साथ लपेट सकते हैं

यहाँ मैं एक टाइपप्रति परियोजना में उपयोग कर रहा हूँ (अंतर्निहित त्रुटि पृष्ठ के आधार पर):

/pages/_error.tsx (या टाइपस्क्रिप्ट प्रकारों को हटा दें और इसे /pages/_error.jsx नाम दें):

import React from 'react';
import Head from 'next/head';
import { NextPageContext } from 'next';

const statusCodes: { [code: number]: string } = {
  400: 'Bad Request',
  404: 'This page could not be found',
  405: 'Method Not Allowed',
  500: 'Internal Server Error'
};

export type ErrorProps = {
  statusCode: number;
  title?: string;
};

/**
 * `Error` component used for handling errors.
 */
export default class Error<P = {}> extends React.Component<P & ErrorProps> {
  static displayName = 'ErrorPage';

  static getInitialProps({
    req,
    res,
    err
  }: NextPageContext): Promise<ErrorProps> | ErrorProps {
    const statusCode =
      res && res.statusCode ? res.statusCode : err ? err.statusCode! : 404;
    if (typeof window === 'undefined') {
      /**
       * Workaround for: https://github.com/zeit/next.js/issues/8913#issuecomment-537632531
       * Test vectors:
       * `/test/test/` -> `/test/test`
       * `/test/////test////` -> `/test/test`
       * `/test//test//?a=1&b=2` -> `/test?a=1&b=2`
       * `/test///#test` -> `/test#test`
       */
      const correctPath = (invalidPath: string) =>
        invalidPath
          .replace(/\/+$/, '')
          .replace(/\/+#/, '#')
          .replace(/\/+\?/, '?')
          .replace(/\/+/g, '/');
      if (req && res && req.url && correctPath(req.url) !== req.url) {
        res.writeHead(302, {
          Location: correctPath(req.url)
        });
        res.end();
      }
      const reqInfo = req
        ? `; Url: ${req.url}; IP: ${req.headers['x-forwarded-for'] ||
            (req.connection && req.connection.remoteAddress)};`
        : '';
      console.log(`Error rendered: ${statusCode}${reqInfo}`);
    }
    return { statusCode };
  }

  render() {
    const { statusCode } = this.props;
    const title =
      this.props.title ||
      statusCodes[statusCode] ||
      'An unexpected error has occurred';

    return (
      <div style={styles.error}>
        <Head>
          <title>
            {statusCode}: {title}
          </title>
        </Head>
        <div>
          <style dangerouslySetInnerHTML={{ __html: 'body { margin: 0 }' }} />
          {statusCode ? <h1 style={styles.h1}>{statusCode}</h1> : null}
          <div style={styles.desc}>
            <h2 style={styles.h2}>{title}.</h2>
          </div>
        </div>
      </div>
    );
  }
}

const styles: { [k: string]: React.CSSProperties } = {
  error: {
    color: '#000',
    background: '#fff',
    fontFamily:
      '-apple-system, BlinkMacSystemFont, Roboto, "Segoe UI", "Fira Sans", Avenir, "Helvetica Neue", "Lucida Grande", sans-serif',
    height: '100vh',
    textAlign: 'center',
    display: 'flex',
    flexDirection: 'column',
    alignItems: 'center',
    justifyContent: 'center'
  },

  desc: {
    display: 'inline-block',
    textAlign: 'left',
    lineHeight: '49px',
    height: '49px',
    verticalAlign: 'middle'
  },

  h1: {
    display: 'inline-block',
    borderRight: '1px solid rgba(0, 0, 0,.3)',
    margin: 0,
    marginRight: '20px',
    padding: '10px 23px 10px 0',
    fontSize: '24px',
    fontWeight: 500,
    verticalAlign: 'top'
  },

  h2: {
    fontSize: '14px',
    fontWeight: 'normal',
    lineHeight: 'inherit',
    margin: 0,
    padding: 0
  }
};

ध्यान दें, जब पृष्ठ हिट होता है तो यह एक त्रुटि भी लॉग करता है, ताकि आप किसी भी लिंक/अन्य मुद्दों को ठीक करने के लिए अपने लॉग की जांच कर सकें।

@DevSpeak @bitjson आपके सुझावों के लिए धन्यवाद। यह निश्चित रूप से इस बारे में जाने का एक तरीका है और निश्चित रूप से इस मुद्दे को बहुत अच्छी तरह से हल करता है। लेकिन इस बात पर विचार करते हुए कि _error.jsx मूल रूप से _errors_ को संभालने के लिए है और घर रूटिंग तर्क नहीं है, मेरी राय में यह सब कोड हैकी और काफी घोषणात्मक है। प्रत्येक उपयोगकर्ता से प्रत्येक कोड बेस में ऐसा करने की अपेक्षा करना एक आवश्यकता नहीं होनी चाहिए - यह बॉक्स से बाहर आना चाहिए। = मेरी राय है कि इस स्थिति को रूटिंग लॉजिक के साथ बनाया जाना चाहिए, रिएक्ट राउटर की तरह ऑप्ट आउट करने के विकल्प के साथ।

@ नथानिएलहिल

यह अगले निर्यात के मामले में भी पूरी तरह से अपरिहार्य है

रुको - मुझे दस्तावेज़ीकरण पढ़ने से समझ में आया कि पिछली स्लैश स्थिति को संभालने के लिए विशिष्ट कोड है:

पृष्ठों को html फ़ाइलों के रूप में निर्यात किया जाएगा, अर्थात /about /about.html बन जाएगा।

पृष्ठों को index.html फ़ाइलों के रूप में निर्यात करने के लिए नेक्स्ट.js को कॉन्फ़िगर करना संभव है और इसके लिए अनुगामी स्लैश की आवश्यकता होती है, अर्थात /about बन जाता है /about/index.html और /about/ के माध्यम से रूट करने योग्य होता है। Next.js 9 से पहले यह डिफ़ॉल्ट व्यवहार था। इस व्यवहार पर वापस जाने के लिए आप निम्नलिखित next.config.js का उपयोग कर सकते हैं:

// next.config.js
module.exports = {
  exportTrailingSlash: true,
}

भले ही यह वास्तव में next export माध्यम से स्थिर HTML निर्यात के लिए एक विकल्प नहीं है, मैं इस तर्क से सहमत नहीं हूं कि सिर्फ इसलिए कि अगला इस (अद्भुत) सुविधा का समर्थन करता है, अन्य मोड को भुगतना पड़ता है (मैं नहीं उपयोग के आँकड़ों को जानते हैं, लेकिन मुझे लगता है कि अधिक लोग सर्वर रहित के विपरीत नियमित रूप से सर्वर मोड का उपयोग करते हैं) खासकर जब यह इस तरह के एक सामान्य उपयोग के मामले के रूप में जाना जाता है

FYI करें: एक RFC है जो आपकी रुचि ले सकती है https://github.com/zeit/next.js/issues/9081

// next.config.js
module.exports = {
  async redirects() {
    return [
      {
        source: "/:path*/",
        destination: "/:path",
        statusCode: 301
      }
    ];
  }
};

@Janpot इसे प्यार करें - यह हमें आधे रास्ते में लाएगा यानी कस्टम सर्वर बनाने के बिना रीडायरेक्ट के लिए किसी प्रकार का समर्थन होगा। यह अभी भी अनिवार्य होने जा रहा है क्योंकि उपयोगकर्ता द्वारा जोड़े जाने वाले प्रत्येक मार्ग के लिए, उन्हें next.config.js में रीडायरेक्ट सेट करना होगा - या शायद हम सभी मामलों को पकड़ने के लिए रेगेक्स का उपयोग कर सकते हैं जैसे @bitjson का उल्लेख किया गया है:

          .replace(/\/+$/, '')
          .replace(/\/+#/, '#')
          .replace(/\/+\?/, '?')
          .replace(/\/+/g, '/')

किसी भी मामले में, यदि कोर टीम इस आरएफसी को प्राथमिकता दे रही है, तो मैं अत्यधिक अनुशंसा करता हूं कि हम एक कदम आगे बढ़ें और इसे _config_ में निर्मित करें ताकि कोई भी इस तरह से

// next.config.js
module.exports = {
  ignoreStrictRoutes: false, // default value: true
};

कुल मिलाकर, मुझे लगता है कि यह एक अच्छा कदम है - अच्छा सामान @Timer !! मैं

@ निक-जॉन जिस पथ को मैंने "/:path*/" में निर्दिष्ट किया है, उसे सभी को पकड़ना चाहिए ( :path एक खंड को पकड़ता है, * इसे 0 से n उदाहरणों को पकड़ता है।)

@ जनपोट आह मेरा बुरा ‍♂ मैं अनुमान लगा रहा हूं कि हमें उस रेगेक्स में किसी भी पिछली क्वेरी पैरा पर भी विचार करना होगा

इसके अलावा, मैं अभी भी दूसरे भाग के साथ खड़ा हूं:

किसी भी मामले में, यदि कोर टीम इस आरएफसी को प्राथमिकता दे रही है, तो मैं अत्यधिक अनुशंसा करता हूं कि हम एक कदम आगे बढ़ें और इसे एक अंतर्निहित कॉन्फ़िगरेशन बनाएं जिससे कोई भी इस तरह से बाहर निकल सके

// next.config.js
module.exports = {
  ignoreStrictRoutes: false, // default value: true
};

यदि आप एक कस्टम सर्वर का उपयोग कर रहे हैं और सख्त मार्गों को अनदेखा करना चाहते हैं तो आप रीडायरेक्ट करने के बजाय कस्टम रूट हैंडलर का भी उपयोग कर सकते हैं।

app.render(req, res, urlWithoutTrailingSlash, query);

इस तरह हम /path और /path/ दोनों का समर्थन करने और एक ही पृष्ठ का समाधान करने में सक्षम हैं।

Oauth फ़ेडरेशन प्रदाताओं को अक्सर अनुगामी फ़ॉरवर्ड स्लैश की आवश्यकता होती है, इसलिए यह व्यवहार एक साधारण प्रवाह को बहुत जटिल बना देता है। इस व्यवहार को लागू करने में तकनीकी चुनौती क्या है? या यह अगले से एक डिजाइन निर्णय है?

मैंने इस धागे में अब तक इसका उल्लेख नहीं देखा है, लेकिन मैं अब के साथ तैनाती के बाद इस समस्या का अनुभव नहीं कर रहा हूं, मैं केवल now dev साथ परीक्षण करते समय इसे स्थानीय रूप से अनुभव कर रहा हूं।

const removeTrailingSlashes = (req, res, expressNext) => {
  if (req.path.substr(-1) === '/' && req.path.length > 1) {
    const query = req.url.slice(req.path.length);
    res.redirect(301, req.path.slice(0, -1) + query);
  } else {
    expressNext();
  }
};

इसे स्टैक ओवरफ्लो से मिला और पूरी तरह से काम किया। यह समाधान एक्सप्रेस के साथ काम करता है।

@ गणेश कथार मैं नहीं देखता कि यह कैसे काम करेगा यदि आप नेक्स्ट.जेएस एक्सप्रेस का उपयोग नहीं कर रहे हैं

मुझे लगता है कि हम इस पर सहमत नहीं हो सकते हैं और यह विन्यास योग्य होना चाहिए।

मैं वास्तव में हमेशा पिछला स्लैश चाहता हूं, सापेक्ष यूआरएल तर्क करना आसान होता है जब सभी पृष्ठ पिछली स्लैश के साथ समाप्त होते हैं।

उदाहरण के लिए इसका कोई मतलब नहीं है कि /about/index.tsx /about बजाय /about/ , लेकिन अब यह समझ में आता है कि अगला स्लैश के बिना उम्मीद करता है। यदि सभी पृष्ठ स्लैश में समाप्त होते हैं, तो यह पृष्ठों को भविष्य में उपपृष्ठों को शामिल करने की अनुमति देगा, जो मुझे लगता है कि पृष्ठों के लिए अधिक एक्स्टेंसिबल तरीका है।

/about/index.tsx फ़ाइल के अंदर सापेक्ष लिंक बनाना अब बोझिल है। यदि आप ./mysubpage/ लिंक बनाते हैं तो यह साइट के रूट की ओर इशारा करता है। यह उपपृष्ठों को गैर-नाम बदलने योग्य बनाता है। मैं एक निर्देशिका नहीं बना सकता /about/ पृष्ठों से भरा है कि मैं सिर्फ नाम बदल सकता हूँ, क्योंकि मुझे जाना चाहिए और सापेक्ष लिंक को भी संपादित करना चाहिए।

साथ ही wget -r साइट हमेशा अनुगामी स्लैश के साथ, index.html फ़ाइलों का उत्पादन करने के साथ समझदार परिणाम उत्पन्न करती है।

हालाँकि, इस सेटिंग को बदलना बड़े पैमाने पर परिवर्तन को तोड़ रहा है क्योंकि सभी साइटें गैर-अनुगामी स्लैश की अपेक्षा करती हैं, इसलिए इसे कॉन्फ़िगर करने योग्य होना चाहिए।

मैं संस्करण 9 का उपयोग कर रहा हूं और यह समस्या अभी भी हल नहीं हुई है

मैं अपने next.config.js पर निम्नलिखित की तरह कुछ का उपयोग करके इसे काम करने में सक्षम था:

exportPathMap: async function() {
  const paths = {
    '/': { page: '/' },
    '/authors/index.html': { page: '/authors' },
  };

  return paths;
},

/authors पहुंचने से 302 location से /authors/ । मैं http-serve साथ परीक्षण कर रहा हूं, यह सुनिश्चित नहीं है कि यह व्यवहार सर्वर-निर्दिष्ट है या नहीं।

जब मुझे इस समस्या का सामना करना पड़ा तो मैं इस समाधान के साथ आया

मेरे _error.js पृष्ठ में

Error.getInitialProps = ({ res, err, asPath }) => {
    const statusCode = res ? res.statusCode : err ? err.statusCode : 404;

    const checkForTrailingSlashes = () => {
        if (asPath.match(/\/$/)) { // check if the path ends with trailing slash
            const withoutTrailingSlash = asPath.substr(0, asPath.length - 1);
            if (res) {
                res.writeHead(302, {
                    Location: withoutTrailingSlash
                })
                res.end()
            } else {
                Router.push(withoutTrailingSlash)
            }
        }
    }

    if (statusCode && statusCode === 404) {
        checkForTrailingSlashes();
    } else {
        // 
    }
    return { statusCode };
}

क्या यह इस मुद्दे को दूर करने का एक अच्छा तरीका है?

इस बारे में कैसा है?

पेज/_app.jsx

``` 'प्रतिक्रिया' से आयात प्रतिक्रिया;
'अगला/ऐप' से ऐप आयात करें;

निर्यात डिफ़ॉल्ट वर्ग MyApp ऐप का विस्तार करता है {
प्रस्तुत करना() {
const {घटक, पेजप्रॉप्स, राउटर: {asPath}} = this.props;

// Next.js currently does not allow trailing slash in a route.
// This is a client side redirect in case trailing slash occurs.
if (asPath.length > 1 && asPath.endsWith('/')) {
  const urlWithoutEndingSlash = asPath.replace(/\/*$/gim, '');

  if (typeof window !== 'undefined') {
    window.location.replace(urlWithoutEndingSlash);
  }
  return null;
}

return <Component {...pageProps} />;

}
}
```

@cnblackxp सुझाव के लिए धन्यवाद। इससे मुझे मदद मिली। गैर-पिछला 404 के लिए डिफ़ॉल्ट व्यवहार रखने के लिए मैंने इसे कैसे कार्यान्वित किया है (यानी मैं डिफ़ॉल्ट Error कार्यान्वयन को फिर से निर्यात कर रहा हूं):

import Error from "next/error";
import Router from "next/router";

export default Error;

Error.getInitialProps = ({ res, err, asPath }) => {
  const statusCode = res ? res.statusCode : err ? err.statusCode : 404;

  if (statusCode && statusCode === 404) {
    if (asPath.match(/\/$/)) {
      const withoutTrailingSlash = asPath.substr(0, asPath.length - 1);
      if (res) {
        res.writeHead(302, {
          Location: withoutTrailingSlash
        });
        res.end();
      } else {
        Router.push(withoutTrailingSlash);
      }
    }
  }

  return { statusCode };
};

हाँ, वह @cansin तब तक

@AlexSapoznikov के समाधान में छोटा सुधार:

  render() {
    const { Component, pageProps, router: { asPath } } = this.props;

    // Next.js currently does not allow trailing slash in a route.
    // This is a client side redirect in case trailing slash occurs.
    if (pageProps.statusCode === 404 && asPath.length > 1 && asPath.endsWith('/')) {

यहां केवल अंतर यह जांच रहा है कि स्थिति कोड 404 है। मुझे गतिशील मार्गों के लिए लिंक का उपयोग करने में समस्याएं आईं, जहां वे हमेशा रीडायरेक्ट के कारण सर्वर पर प्रतिपादन कर रहे थे। यदि आप क्लाइंट-साइड रूटिंग को काम करना चाहते हैं, तो आप लिंक href प्रोप में पिछला स्लैश नहीं जोड़ सकते हैं, लेकिन फिर आपको यह सुनिश्चित करने की ज़रूरत है कि आप इस मामले में रीडायरेक्ट नहीं करते हैं।

त्रुटि घटक में वर्कअराउंड को लागू करने में समस्या यह है कि यह विकास में त्रुटि को सूचित करेगा जो मुझे परेशान करता है। मेरे पिछले क्लाइंट साइड रीडायरेक्ट में कुछ सुधार:

क्या सुधार हुआ है कि अब यह क्लाइंट साइड में नेक्स्ट/राउटर का उपयोग करता है और यूआरएल रिप्लेसमेंट बिना रीलोड के होता है।

पेज/_app.jsx

import App from 'next/app';
import Router from 'next/router';

export default class MyApp extends App {
  render() {
    const { Component, pageProps, router: { asPath, route } } = this.props;

    // Next.js currently does not allow trailing slash in a route.
    // This is a client side redirect in case trailing slash occurs.
    if (pageProps.statusCode === 404 && asPath.length > 1 && asPath.endsWith('/')) {
      const routeWithoutEndingSlash = route.replace(/\/*$/gim, '');
      const asPathWithoutEndingSlash = asPath.replace(/\/*$/gim, '');

      if (typeof window !== 'undefined') {
        Router.replace(routeWithoutEndingSlash, asPathWithoutEndingSlash);
      }
      return null;
    }

    return <Component {...pageProps} />;
  }
}

404 फिक्स के लिए @mbrowne को भी धन्यवाद :)

@cansin का समाधान लिया और क्वेरी पैरामीटर को संभालने की क्षमता को जोड़ा

MyError.getInitialProps = async ({ res, err, asPath }) => {
  // Capture 404 of pages with traling slash and redirect them
  const statusCode = res 
    ? res.statusCode
    : (err ? err.statusCode : 404);

  if (statusCode && statusCode === 404) {
    const [path, query = ''] = asPath.split('?');                                                                                                                                                                                             
    if (path.match(/\/$/)) {
      const withoutTrailingSlash = path.substr(0, path.length - 1); 
      if (res) {
        res.writeHead(302, {
          Location: `${withoutTrailingSlash}${query ? `?${query}` : ''}`,
        }); 
        res.end();
      } else {
        Router.push(`${withoutTrailingSlash}${query ? `?${query}` : ''}`);
      }   
    }   
  }

@pinpointcoder क्या आप एक यूआरएल के उदाहरण प्रदान कर सकते हैं जिसमें पिछली स्लैश और क्वेरी पैरामीटर एक ही समय में होते हैं? क्या आप /blog/?123 तर्ज पर सोच रहे हैं?

ऊपर दिए गए आपके कुछ कामकाज के लिए सभी को धन्यवाद। उन्होंने काम किया!

हालांकि, क्या हमारे पास नेक्स्ट की टीम से इस समस्या को ठीक करने का कोई आधिकारिक तरीका है? यह मुद्दा यहां सालों से है।

निर्देशिका पृष्ठ अगले निर्यात में अनुगामी स्लैश के साथ प्रस्तुत नहीं किए जाते हैं

@pinpointcoder क्या आप एक यूआरएल के उदाहरण प्रदान कर सकते हैं जिसमें पिछली स्लैश और क्वेरी पैरामीटर एक ही समय में होते हैं? क्या आप /blog/?123 तर्ज पर सोच रहे हैं?

@coodoo उसे नहीं, लेकिन हाँ, दुर्भाग्य से ऐसा बहुत होता है। मैं वर्तमान में एक WordPress साइट को Next.js पर क्रमिक रूप से माइग्रेट करने की प्रक्रिया में हूं, और किसी कारण से, मूल "डेवलपर्स" ने प्रत्येक URL पर एक अनुगामी स्लैश को बाध्य करने का निर्णय लिया, इसलिए वर्तमान में हमारे पास अनुगामी दोनों के साथ बहुत सारे अनुरोध हैं स्लैश और क्वेरी पैरामीटर।

जैसा कि हम कई ब्लॉग पोस्ट माइग्रेट करने वाले हैं, जिसके लिए कैननिकल यूआरएल में वर्तमान में एक पिछला स्लैश शामिल है, यह अभी मेरे गधे में एक बड़ा दर्द है।

मैंने इसे संभालने के लिए एक कस्टम सर्वर को लागू करने का फैसला किया और यह पता चला कि यह करना आसान है, और आप अभी भी next.js की फ़ाइल-आधारित रूटिंग सिस्टम का उपयोग कर सकते हैं। इस तरह आप उस URL को फिर से लिख सकते हैं जिसे next.js देखता है और असली URL के अंत में अभी भी एक स्लैश है:

const { createServer } = require('http')
const { parse } = require('url')
const next = require('next')
const conf = require('./next.config.js')

const PORT = process.env.PORT || 5000

const dev = process.env.NODE_ENV !== 'production'
const app = next({ dev, conf })
const handle = app.getRequestHandler()

app.prepare().then(() => {
    createServer((req, res) => {
        // If there is a slash at the end of the URL, remove it before sending it to the handle() function.
        // This is a workaround for https://github.com/zeit/next.js/issues/5214
        const url =
            req.url !== '/' && req.url.endsWith('/')
                ? req.url.slice(0, -1)
                : req.url
        // Be sure to pass `true` as the second argument to `url.parse`.
        // This tells it to parse the query portion of the URL.
        const parsedUrl = parse(url, true)

        handle(req, res, parsedUrl)
    }).listen(PORT, err => {
        if (err) throw err
        console.log(`> Ready on http://localhost:${PORT}`)
    })
})

देखें https://nextjs.org/docs/advanced-features/custom-server

@mbrowne हमारे पास वास्तव में एक कस्टम सर्वर का उपयोग करने के कारणों का एक समूह है, लेकिन मुख्य बात जिसने मुझे अब तक एक को लागू करने से रोका है, वह यह है कि आप स्वचालित स्टेटिक ऑप्टिमाइज़ेशन खो देते हैं। क्या आप जानते हैं कि क्या स्थैतिक मार्गों को मैन्युअल रूप से निर्दिष्ट करना संभव है?

हमें इस समय अपने ऐप के लिए स्वचालित स्थैतिक अनुकूलन की आवश्यकता नहीं है, इसलिए मैंने इस पर ध्यान नहीं दिया।

मैं कस्टम सर्वर का भी उपयोग कर रहा हूं, लेकिन जब आप संशोधित (बिना प्रमुख स्लैश के) url को handle , तो SSR क्लाइंट साइड से अलग url देखता है।
मैं उन खराब हैक्स के बिना प्रमुख स्लैश के साथ यूआरएल से मेल खाने के लिए next राउटर पसंद करूंगा।

2020 और यह बग अभी भी होता है। अविश्वसनीय

यह एक खराब बग है जिसे वास्तव में ठीक करने की आवश्यकता है। /products काम करता है, लेकिन /products/ नहीं करता है। इस लिंक के साथ

<Link href="/products">
  <a>Products</a>
</Link>

मुझे समझ आ गया

index.js:1 Warning: Prop `href` did not match. Server: "/products" Client: "/products/"

हालांकि, अगर मैं लिंक को /products/ इंगित करता हूं, लिंक पर जाता हूं, और विकास के दौरान पृष्ठ को रीफ्रेश करता हूं, तो मुझे 404 मिलता है। यह काफी दर्दनाक विकास अनुभव है।

यह मुद्दा पहली बार 1.5 साल पहले रिपोर्ट किया गया था; क्या हम कृपया आधिकारिक सुधार प्राप्त कर सकते हैं? यह अभी भी 9.3.4 में मौजूद है।

मैंने एसईओ कारणों से सामग्री दिखाने के बजाय गैर-पिछली स्लैश यूआरएल पर पुनर्निर्देशन किया।

app.prepare().then(() => {
  createServer((req, res) => {
    if (req.url !== '/' && req.url.endsWith('/')) {
      res.writeHead(301, { Location: req.url.slice(0, -1) })
      res.end()
    }
    handle(req, res, parse(req.url, true))
  }).listen(PORT, err => {
    if (err) throw err
    console.log(`> Ready on http://localhost:${PORT}`)
  })
})

SEO के लिए, rel="canonical" मदद कर सकता है, लेकिन फिर भी इस 404 समस्या को ठीक करने की आवश्यकता है।

यह एक खराब बग है जिसे वास्तव में ठीक करने की आवश्यकता है। /products काम करता है, लेकिन /products/ नहीं करता है। इस लिंक के साथ

<Link href="/products">
  <a>Products</a>
</Link>

मुझे समझ आ गया

index.js:1 Warning: Prop `href` did not match. Server: "/products" Client: "/products/"

हालांकि, अगर मैं लिंक को /products/ इंगित करता हूं, लिंक पर जाता हूं, और विकास के दौरान पृष्ठ को रीफ्रेश करता हूं, तो मुझे 404 मिलता है। यह काफी दर्दनाक विकास अनुभव है।

यह मुद्दा पहली बार 1.5 साल पहले रिपोर्ट किया गया था; क्या हम कृपया आधिकारिक सुधार प्राप्त कर सकते हैं? यह अभी भी 9.3.4 में मौजूद है।

मुझे भी वर्तमान में यह मुद्दा मिल रहा है।

यहां बताया गया है कि मैंने इसे कैसे ठीक किया, https://medium.com/@thisisayush/handling -404-trailing-slash-error-in-nextjs-f8844545afe3

यहां बताया गया है कि मैंने इसे कैसे ठीक किया, https://medium.com/@thisisayush/handling -404-trailing-slash-error-in-nextjs-f8844545afe3

धन्यवाद, हालांकि स्थानीय रूप से विकसित करते समय इसके लिए एक कस्टम सर्वर की आवश्यकता होती है, और इसकी आवश्यकता नहीं होनी चाहिए।

@timneutkens किसी भी मौके पर इस मुद्दे को ठीक करने के लिए विकास कार्यक्रम में काम किया जा सकता है?

इससे भी महत्वपूर्ण बात यह है कि रीडायरेक्ट समाधान उन लोगों के लिए काम नहीं करता है जो उत्पादन में एक को हटाने के बजाय एक स्लैश जोड़ने के लिए पहले से ही सेट की गई साइटों का रखरखाव कर रहे हैं। मुझे नहीं लगता कि ढांचे को इस विकल्प को मनमाने ढंग से निर्धारित करना चाहिए।

@AlexSapoznikov के समाधान ने हमारे लिए Netlify (जो डिफ़ॉल्ट रूप से अनुगामी स्लैश जोड़ता है) के साथ अच्छा काम किया। यहां एक उन्नत संस्करण है जो क्वेरी पैराम्स के लिए समर्थन जोड़ता है:

import App from "next/app";

export default class MyApp extends App {
  render() {
    const { Component, pageProps, router, router: { asPath } } = this.props;

    // Next.js currently does not allow trailing slash in a route, but Netlify appends trailing slashes. This is a
    // client side redirect in case trailing slash occurs. See https://github.com/zeit/next.js/issues/5214 for details
    if (asPath && asPath.length > 1) {
      const [path, query = ""] = asPath.split("?");
      if (path.endsWith("/")) {
        const asPathWithoutTrailingSlash = path.replace(/\/*$/gim, "") + (query ? `?${query}` : "");
        if (typeof window !== "undefined") {
          router.replace(asPathWithoutTrailingSlash, undefined, { shallow: true });
          return null;
        }
      }
    }

    return <Component {...pageProps} />;
  }
}

मैं क्षमा चाहता हूं क्योंकि मैं एक अगला जेएस नौसिखिया हूं, हालांकि मेरे पास अन्य एसडीके और प्लेटफॉर्म पर सॉफ्टवेयर विकास का अनुभव है।

मुझे लगता है कि इस "बग" ने मुझे सबसे ज्यादा हैरान किया। मेरे लिए, इसने "कम से कम विस्मय के सिद्धांत" का उल्लंघन किया। मुझे बस उम्मीद थी कि मेरा /about/ और /about वही काम करेगा, क्योंकि मैंने अपने /pages/about/ फ़ोल्डर में index.tsx रखा है।

मैंने पहली बार 1990 के दशक के अंत में अपने सर्वर पर HTML FTP'd के साथ वेब साइट बनाना शुरू किया, और बाद में PHP और Apache, और अंततः जावा सर्वर पर चला गया। अब मैं मोबाइल ऐप्स में विशेषज्ञ हूं। यह मेरे लिए अजीब लगता है कि यह व्यवहार डिफ़ॉल्ट नहीं है, और मुझे इसे अपने देव सर्वर पर ठीक करने के लिए एक कस्टम सर्वर पेज लिखना होगा।

मैं एक स्थिर निर्यात करने की योजना बना रहा हूं, इसलिए यह उत्पादन में दिखाई नहीं देगा, भले ही मैं कस्टम सर्वर न लिखूं। हालांकि यह देव और डिबगिंग को थोड़ा अधिक परेशान करता है।

क्या हम एक "अगला देव" ध्वज प्राप्त कर सकते हैं जो इसे ठीक करता है इसलिए हम आलसी डेवलपर्स को केवल देव/डीबग समय के लिए अतिरिक्त रूटिंग तर्क लिखने की आवश्यकता नहीं है?

धन्यवाद!

पीएस: हां, मुझे पता है कि /about और /about/ पूरी तरह से अलग यूआरएल हैं। जब मैंने अपने /pages/about/ फ़ोल्डर के अंदर एक index.tsx फ़ाइल डाली, तो मैं वास्तव में भ्रमित हो गया, और पाया कि यह केवल /about पथ के साथ काम करता है लेकिन /about/ साथ काम नहीं करता है /about/ । अगर यह दूसरी तरफ होता तो मुझे कम आश्चर्य होता।

pps: जब मेरे पास <Link></Link> घटक होता है जो /about/ इशारा करता है तो यह अतिरिक्त भ्रमित करने वाला था और यह अपेक्षा के अनुरूप काम करता है। फिर जब मैंने अपने ब्राउज़र पर रीफ्रेश किया, तो यह तुरंत 404 हो गया, भले ही यूआरएल नहीं बदला। यह बहुत आश्चर्य की बात थी। :-डी

लेकिन यह खराब हो जाता है, रुको! हम एक कस्टम जोड़ा checkForTrailingSlash अंदर समारोह _error.js कि स्लैश और रीडायरेक्ट पट्टी होगी। यह कुछ समय तक ठीक रहा जब तक कि हमने (आखिरकार) एक कस्टम 404 पेज जोड़ा और पाया कि कस्टम 404 पेज के साथ, Next.js पूरी तरह से Error बायपास कर देता है । इसका मतलब है कि Error.getInitialProps अंदर आपका कोई भी कस्टम तर्क अब काम नहीं करेगा - पिछली स्लैश के लिए चेक सहित।

मान लीजिए कि मैं _app.js समाधान दूसरों का उल्लेख करने का प्रयास करूंगा, क्योंकि एक कस्टम सर्वर अभी तक एक संभावना नहीं है।

@AlexSapoznikov के समाधान ने हमारे लिए Netlify (जो डिफ़ॉल्ट रूप से अनुगामी स्लैश जोड़ता है) के साथ अच्छा काम किया। यहां एक उन्नत संस्करण है जो क्वेरी पैराम्स के लिए समर्थन जोड़ता है:

import App from "next/app";

export default class MyApp extends App {
  render() {
    const { Component, pageProps, router, router: { asPath } } = this.props;

    // Next.js currently does not allow trailing slash in a route, but Netlify appends trailing slashes. This is a
    // client side redirect in case trailing slash occurs. See https://github.com/zeit/next.js/issues/5214 for details
    if (asPath && asPath.length > 1) {
      const [path, query = ""] = asPath.split("?");
      if (path.endsWith("/")) {
        const asPathWithoutTrailingSlash = path.replace(/\/*$/gim, "") + (query ? `?${query}` : "");
        if (typeof window !== "undefined") {
          router.replace(asPathWithoutTrailingSlash, undefined, { shallow: true });
          return null;
        }
      }
    }

    return <Component {...pageProps} />;
  }
}

आपके कोड नमूने में एक गंभीर त्रुटि है: एक क्वेरी पैरामीटर के साथ अनुक्रमणिका मार्ग के लिए अनुरोध एक त्रुटि देगा, क्योंकि आप केवल क्वेरी स्ट्रिंग को Next.js को asPath रूप में पास करने का प्रयास करते हैं।

यह इसे ठीक करता है:

  if (asPath && asPath.length > 1) {
    const [path, query = ''] = asPath.split('?');
    if (path.endsWith('/') && path.length > 1) {
      const asPathWithoutTrailingSlash =
        path.replace(/\/*$/gim, '') + (query ? `?${query}` : '');
      if (typeof window !== 'undefined') {
        router.replace(asPathWithoutTrailingSlash, undefined, {
          shallow: true,
        });
        return null;
      }
    }
  }

SSR के साथ यह काम करने के लिए मुझे @pjaws और @AlexSapoznikov समाधान में निम्नलिखित जोड़ना पड़ा:

  static async getInitialProps({ Component, ctx, router }) {
    /* Fixes the trailing-slash-404 bug for server-side rendering. */
    const { asPath } = router;
    if (asPath && asPath.length > 1) {
      const [path, query = ""] = asPath.split("?");
      if (path.endsWith("/") && path.length > 1) {
        const asPathWithoutTrailingSlash =
          path.replace(/\/*$/gim, "") + (query ? `?${query}` : "");
        if (ctx.res) {
          ctx.res.writeHead(301, {
            Location: asPathWithoutTrailingSlash,
          });
          ctx.res.end();
        }
      }
    }
    return {
      pageProps: Component.getInitialProps
        ? await Component.getInitialProps(ctx)
        : {},
    };
  }

संभवतः यह एक अच्छा विचार है कि किसी तरह इस कार्यक्षमता को एक ऐसे फ़ंक्शन में सामान्यीकृत किया जाए जो SSR और CSR दोनों के दौरान काम करता है और इसे दोनों स्थानों ( getInitialProps और render ) में कॉल करता है।

द्वारा

यह ठीक हो जाएगा लेकिन शीर्षक गलत है। हम्म

@AlexSapoznikov @pjaws

आपका समाधान हमें अनंत लूप में डालता है:

  if (asPath && asPath.length > 1) {
    const [path, query = ''] = asPath.split('?');
    if (path.endsWith('/') && path.length > 1) {
      const asPathWithoutTrailingSlash =
        path.replace(/\/*$/gim, '') + (query ? `?${query}` : '');
      if (typeof window !== 'undefined') {
        router.replace(asPathWithoutTrailingSlash, undefined, {
          shallow: true,
        });
        return null;
      }
    }
  }

संदर्भ

हमारे नियंत्रण से परे कारणों के कारण, हम उपयोग करने के लिए exportTrailingSlash में विकल्प next.config.js ।

हम दूसरे पेज का लिंक चाहते हैं लेकिन हम चाहते हैं कि लिंक /somepage?param=whatever ।

ऐसा लगता है कि अगला लिंक इसे /somepage/?param=whatever और हमें पेज नहीं मिला।

ऊपर दिए गए समाधान का उपयोग करने से पैराम समस्या हल हो जाती है, लेकिन फिर /somepage/ जैसे परिनियोजित पृष्ठ पर जाने पर यह एक अनंत लूप में प्रवेश करता है।

मुझे लगता है कि @ronyeh ने यहां वास्तव में एक अच्छा मुद्दा बनाया है, इसलिए मैं वास्तव में इस मुद्दे के लिए एक आधिकारिक समाधान चाहता हूं :(

SSR के साथ यह काम करने के लिए मुझे @pjaws और @AlexSapoznikov समाधान में निम्नलिखित जोड़ना पड़ा:

  static async getInitialProps({ Component, ctx, router }) {
    /* Fixes the trailing-slash-404 bug for server-side rendering. */
    const { asPath } = router;
    if (asPath && asPath.length > 1) {
      const [path, query = ""] = asPath.split("?");
      if (path.endsWith("/") && path.length > 1) {
        const asPathWithoutTrailingSlash =
          path.replace(/\/*$/gim, "") + (query ? `?${query}` : "");
        if (ctx.res) {
          ctx.res.writeHead(301, {
            Location: asPathWithoutTrailingSlash,
          });
          ctx.res.end();
        }
      }
    }
    return {
      pageProps: Component.getInitialProps
        ? await Component.getInitialProps(ctx)
        : {},
    };
  }

संभवतः यह एक अच्छा विचार है कि किसी तरह इस कार्यक्षमता को एक ऐसे फ़ंक्शन में सामान्यीकृत किया जाए जो SSR और CSR दोनों के दौरान काम करता है और इसे दोनों स्थानों ( getInitialProps और render ) में कॉल करता है।

इसने getServerSideProps वाले पृष्ठों के लिए काम किया है और अब अनुगामी स्लैश वाले url 404 के बिना एक ही पृष्ठ पर लौट रहे हैं।
लेकिन एक गड़बड़ है, मेरे पास कुछ पृष्ठ हैं जो गतिशील मार्गों का उपयोग करते हैं और स्टेटिकपाथ प्राप्त करते हैं, मैं उन पर getServerSideProps का उपयोग नहीं कर सकता और इस प्रकार जब इन गतिशील मार्गों को पिछली स्लैश के साथ ब्राउज़ किया जाता है, तो वे पहले 404 लौटाते हैं और फिर वे पृष्ठ पर रीडायरेक्ट करते हैं .

मैं एक /api/test फ़ोल्डर के साथ काम कर रहा हूँ

• पेज/एपीआई/test.tsx
• पेज/एपीआई/टेस्ट/[आईडी] .tsx

यह के लिए काम करता है

• प्राप्त / एपीआई / परीक्षण
• प्राप्त / एपीआई / परीक्षण / 123
• प्राप्त / एपीआई / परीक्षण / 123 /

और मुझे अभी पता चला है कि यह काम नहीं करता

• प्राप्त / एपीआई / परीक्षण /

सुनिश्चित नहीं है कि यह संबंधित मुद्दा है
पी/डी एक्सपोर्टट्रेलिंगस्लैश = सच इसे हल नहीं करता है

यह एक बहुत पुराना मुद्दा है, क्या कोई कारण है कि इसे इतने लंबे समय तक संबोधित नहीं किया गया?

मुझे यकीन नहीं है कि अब क्या काम नहीं कर रहा है।

मेरी समझ यह है कि आवश्यकताएं इस प्रकार हैं:

| | एक्सपोर्टट्रेलिंगस्लैश: असत्य | एक्सपोर्टट्रेलिंगस्लैश: सच |
|---------------------------|-------------------------- -----|--------------------------|
| url / | . के साथ समाप्त होता है काम नहीं करना चाहिए | काम करना चाहिए |
| url /| . के साथ समाप्त नहीं होता है काम करना चाहिए | काम नहीं करना चाहिए |

यह अपेक्षा के अनुरूप काम करता है जहां:

• स्थानीय रूप से हम exportTrailingSlash: false
• परिनियोजन (उत्पादन बिल्ड) के लिए हम exportTrailingSlash: true और एक nginx url/ को url/index.html परिवर्तित करता है

मैं @ andrescabana86 में जो देख सकता हूं GET /api/test/123/ जबकि GET /api/test/ काम नहीं करता है और इसे नहीं करना चाहिए।

@Izhaki मैंने दोनों की कोशिश की, ठेस पर तैनाती ... और मेरे लिए काम नहीं कर रहा है

• प्राप्त करें / एपीआई / परीक्षण /

और मैं उपयोग कर रहा हूँ exportTrailingSlash: true

यदि आप चाहें तो मैं एक सार्वजनिक रेपो बनाने की कोशिश कर सकता हूं, शायद मैं बीच में कुछ भूल गया।

आपके जवाबों के लिए धन्यवाद

@ andrescabana86 मुझे यकीन नहीं है कि एक सार्वजनिक रेपो यहां कितनी मदद करेगा - यह आपके द्वारा तैनात सर्वर पर कुछ कॉन्फ़िगरेशन भी हो सकता है।

हम स्थानीय रूप से इस स्क्रिप्ट का उपयोग करके package.json अपने प्रोडक्शन बिल्ड ( exportTrailingSlash: true ) का परीक्षण कर रहे हैं:

"serve:out": "docker run --rm -v $(pwd)/out:/static -p 5000:80 flashspys/nginx-static"

कृपया मुझे बताएं कि क्या आपके ब्राउज़र में http://localhost:5000/api/test/ काम करता है।

(ध्यान दें कि $(pwd) मैक/लिनक्स पर है - इसे विंडोज़ के लिए देखें)

@Izhaki समस्या इस तथ्य के बारे में थी कि (जैसा कि प्रारंभिक रिपोर्ट से पता चलता है) "कानूनी पृष्ठ के लिंक में पिछला स्लैश क्लाइंट साइड नेविगेशन के लिए काम करता है लेकिन हार्ड रीफ्रेश (एसएसआर) पर बंडल और 404 नहीं मिला"। इसलिए क्लाइंट-साइड रूट परिवर्तन, बनाम हार्ड रिफ्रेश के व्यवहार के बीच एक बेमेल था। मुझे यकीन नहीं है कि समस्या Next.js के नवीनतम संस्करण के साथ बनी रहती है। एक बार परीक्षण करने के बाद मैं यहां वापस रिपोर्ट कर सकता हूं।

बस 9.4.1 और exportTrailingSlash: true साथ परीक्षण किया गया।

स्थानीय रूप से विकसित होने पर http://localhost:6500/admin/ जाकर 404 लौटाता है।

लेकिन जब आप निर्यात करते हैं तो वही रास्ता काम करता है।

ध्यान दें कि exportTrailingSlash संकेत देता है कि यह केवल _exports_ के लिए है।

हम क्या करते हैं उपयोग है:

exportTrailingSlash: process.env.NODE_ENV === 'production'

इसका मतलब है कि जब हम स्थानीय रूप से विकसित होते हैं तो चीजें इरादे से काम करती हैं। और तैनात होने पर (निर्यात के माध्यम से) ठीक से काम करें।

क्या यह इसके लिए सही और व्यवहार्य समाधान नहीं है?

अगर कोई यूआरएल विकास पर काम नहीं करता है लेकिन उत्पादन पर काम करता है, तो क्या आपको नहीं लगता कि यह कम से कम आश्चर्य के सिद्धांत के खिलाफ है? मुझे लगता है कि इसे अभी भी एक बग माना जाना चाहिए।

^ उस ने कहा, मुझे पूरा यकीन है कि पहले उत्पादन पर एक पृष्ठ रीफ्रेश बनाम राउटर.पुश घटना के बीच एक विरोधाभासी व्यवहार था। मुझे नहीं पता कि क्या अब भी ऐसा है।

@andrescabana86 @Izhaki exportTrailingSlash असंबंधित है। वह विकल्प Next.js अनुप्रयोगों के स्थिर निर्यात से संबंधित है। जब सही होता है, example/index.html उत्पन्न होता है, जबकि जब यह गलत होता है, तो example.html उत्पन्न होता है। मेरी समझ यह है कि exportTrailingSlash का विकास मोड से कोई लेना-देना नहीं है।

मुझे लगता है कि भ्रम का एक स्रोत यह है कि जब आपके पास exportTrailingSlash next.js होता है तो लिंक में पिछला स्लैश जोड़ता है। यह विकास में भी होता है मुझे यकीन नहीं है कि इसे ऐसा करना चाहिए? लेकिन किसी भी तरह, यह केवल example/index.html बनाम example.html - आपको संशोधित करने के लिए लिंक की भी आवश्यकता है।

अगर कोई यूआरएल विकास पर काम नहीं करता है लेकिन उत्पादन पर काम करता है, तो क्या आपको नहीं लगता कि यह कम से कम आश्चर्य के सिद्धांत के खिलाफ है? मुझे लगता है कि इसे अभी भी एक बग माना जाना चाहिए।

मैं गलत हो सकता हूं, लेकिन ExportTrailingSlash विकल्प nginx सर्वर के लिए था जो /something.html परोसने के लिए कॉन्फ़िगर नहीं किए गए हैं जब url /something ।

स्थानीय देव के लिए उपयोग किए जाने वाले अगले सर्वर के मामले में ऐसा नहीं है। तो क्या काम करता है और क्या नहीं यह इस बात पर निर्भर करता है कि आपके ऐप में क्या काम करता है।

आप एक मामला बना सकते हैं कि जब exportTrailingSlash सत्य है, तो अगले सर्वर को ट्रेलिंग स्लैश के साथ समाप्त होने वाले मार्गों का समर्थन करना चाहिए (हालांकि यह export को exportTrailingSlash कुछ हद तक अप्रासंगिक बना देगा)।

FWIW इस पर पहले से ही काम किया जा रहा है #13333

मैं बहुत अनुभवी कोडर नहीं हूं, मुख्य रूप से बहु-पृष्ठ वाली लैंडिंग के लिए Next.js का उपयोग करता हूं। जाहिर है, मैं लगभग हर समय निम्नलिखित समाधान का उपयोग कर रहा हूं, इसके प्रभाव से अनजान। यहाँ इसका छीन लिया गया संस्करण है:

// In your server.js
server.get('/:id', (req, res) => {
  const actualPage = `/${req.params.id}`
  app.render(req, res, actualPage)
})

मेरे मामले में कोड थोड़ा अधिक जटिल है, क्योंकि मैं इसका उपयोग अतिरिक्त स्थिर यूआरएल उपसर्गों आदि का समर्थन करने के लिए कर रहा हूं। लेकिन यह छीन लिया गया संस्करण exportTrailingSlash परवाह किए बिना चर्चा की गई समस्या के लिए ठीक काम कर रहा है। सेटिंग और उसका प्रभाव Link s पर। जैसे यूआरएल /about और /about/ ठीक काम करते हैं।

वर्तमान रूप में यह अनिवार्य रूप से Next.js की मूल रूटिंग की नकल करता है। नकारात्मक पक्ष: इसके लिए कस्टम server.js आवश्यकता होती है, और आपको इसे "गहरे" URL (अतिरिक्त "सबफ़ोल्डर्स" के साथ) के लिए मैन्युअल रूप से समर्थन देना होगा, जैसे /company/about/ । लेकिन यह उन लोगों के लिए अपेक्षाकृत सरल समाधान प्रतीत होता है जो पहले से ही अपने प्रोजेक्ट में कस्टम server.js का उपयोग करते हैं।

SSR के साथ यह काम करने के लिए मुझे @pjaws और @AlexSapoznikov समाधान में निम्नलिखित जोड़ना पड़ा:

  static async getInitialProps({ Component, ctx, router }) {
    /* Fixes the trailing-slash-404 bug for server-side rendering. */
    const { asPath } = router;
    if (asPath && asPath.length > 1) {
      const [path, query = ""] = asPath.split("?");
      if (path.endsWith("/") && path.length > 1) {
        const asPathWithoutTrailingSlash =
          path.replace(/\/*$/gim, "") + (query ? `?${query}` : "");
        if (ctx.res) {
          ctx.res.writeHead(301, {
            Location: asPathWithoutTrailingSlash,
          });
          ctx.res.end();
        }
      }
    }
    return {
      pageProps: Component.getInitialProps
        ? await Component.getInitialProps(ctx)
        : {},
    };
  }

संभवतः यह एक अच्छा विचार है कि किसी तरह इस कार्यक्षमता को एक ऐसे फ़ंक्शन में सामान्यीकृत किया जाए जो SSR और CSR दोनों के दौरान काम करता है और इसे दोनों स्थानों ( getInitialProps और render ) में कॉल करता है।

इसने getServerSideProps वाले पृष्ठों के लिए काम किया है और अब अनुगामी स्लैश वाले url 404 के बिना एक ही पृष्ठ पर लौट रहे हैं।
लेकिन एक गड़बड़ है, मेरे पास कुछ पृष्ठ हैं जो गतिशील मार्गों का उपयोग करते हैं और स्टेटिकपाथ प्राप्त करते हैं, मैं उन पर getServerSideProps का उपयोग नहीं कर सकता और इस प्रकार जब इन गतिशील मार्गों को पिछली स्लैश के साथ ब्राउज़ किया जाता है, तो वे पहले 404 लौटाते हैं और फिर वे पृष्ठ पर रीडायरेक्ट करते हैं .

@gauravkrp यह वास्तव में एक अत्यंत महत्वपूर्ण जोड़ है, क्योंकि @AlexSapoznikov समाधान वास्तव में अभी भी Google को पृष्ठ के लिए 404 लौटाएगा (चूंकि क्लाइंट पर रीडायरेक्ट होता है)। मुझे लगता है कि SEO एक प्रमुख कारण है कि हम में से बहुत से लोग पहले स्थान पर Next.js का उपयोग कर रहे हैं।

मुझे यह भी लगता है कि इसे getInitialProps में डालने से बस चारों ओर काम करना चाहिए, और मुख्य समारोह के अंदर का टुकड़ा इस बिंदु पर अनावश्यक है। यहां प्रमुख चेतावनी यह है कि आप इसे होने से स्वचालित स्टेटिक ऑप्टिमाइज़ेशन खो रहे हैं - शायद 404 के समूह से बेहतर।

कुछ साझा करने के लिए...

मेरा प्रोजेक्ट Express + Next.js ।
express 4.17.1
next 9.4.5-canary.7

जब विकास

गतिशील रनटाइम

// next.config.js
module.exports = {
  exportTrailingSlash: false,
};

// app.js
const Next = require('next').default;
const NextApp = Next({ dev });
const NextHandler = NextApp.getRequestHandler();
NextApp.prepare();
app.get('*', (req, res) => NextHandler(req, res));

जब उत्पादन

स्थिर निर्यात
next build और next export -o dist/ चलाएँ

// next.config.js
module.exports = {
  exportTrailingSlash: true,
};

// app.js
app.use('/_next', express.static('dist/_next', { etag: true, index: false, maxAge: '365d', redirect: false, dotfiles: 'ignore' }));
app.use('/fonts', express.static('dist/fonts', { etag: true, index: false, maxAge: '365d', redirect: false, dotfiles: 'ignore' }));
app.use('/img', express.static('dist/img', { etag: true, index: false, maxAge: '365d', redirect: false, dotfiles: 'ignore' }));
app.use(express.static('./dist', { index: ['index.html'] }));
app.use((req, res) => {
  res.Redirect('/404'); // <- Express will auto handle both /404 or /404/
});

निष्कर्ष के तौर पर

क्लाइंट ऐप पर क्लिक करके रीडायरेक्ट करते समय मुझे कोई समस्या नहीं है,
static route पर भी हार्ड रिफ्रेश काम कर रहा है।

लेकिन dynamic route पर हार्ड रीफ्रेश होने पर यह 404 हो जाएगा,
जैसे /album/[id].jsx या /album/123 ,
इसलिए मैं निम्नलिखित तंत्र का उपयोग करके इस समस्या को ठीक करने के लिए उत्सुक हूं।

जैसे
/album/123 पर 404 हिट करने पर,
सर्वर को html सामग्री प्रदान करना जारी रखना चाहिए,
ब्राउज़र बिना किसी समस्या के पेज लोड करना जारी रखेगा,
जब Next.js बूट हो जाता है तो next/router इसे स्वतः संभाल लेना चाहिए।

क्या उत्पादन पर इस मुद्दे का कोई अस्थायी समाधान है?

हम इसे ठीक करने वाली एक विशेषता को उतारने जा रहे हैं—एक-एक दिन!

क्या उत्पादन पर इस मुद्दे का कोई अस्थायी समाधान है?

इस सूत्र में कई हैं, लेकिन मैं वर्तमान में @gauravkrp द्वारा हाल ही में पोस्ट की

आप यहां पीआर का ट्रैक रख सकते हैं: #13333

इसे अब next@^9.4.5-canary.17 में हल कर लिया गया है!

फीचर को कैनरी से मास्टर तक पहुंचने में कितना समय लगता है?

इसे अब next@^9.4.5-canary.17 में हल कर लिया गया है!

और यह वास्तव में कैसे हल किया जाता है? बस पिछला स्लैश हटा रहा है? यदि मैं " www.site.com/help/ " तक www.site.com/help ", क्या हमारे पास एक विकल्प हो सकता है जहाँ हम अंतिम स्लैश को छोड़ने का विकल्प चुनते हैं? " www.site.com/help/ " या " www.site.com/help " तक पहुंचना छोड़ देगा या रीडायरेक्ट करेगा या अंत में "/" जोड़ देगा: " www.site.com/help/ "

@Valnexus #13333 देखें, इसमें एक प्रयोगात्मक विकल्प शामिल है:

module.exports = {
  experimental: {
    trailingSlash: true
  }
}

फीचर को कैनरी से मास्टर तक पहुंचने में कितना समय लगता है?

जब यह तैयार हो जाए। हैंडलिंग में अभी भी किनारे के मामले हैं जिन्हें हल किया जा रहा है। एक बार उन्हें ठीक कर लिया गया तो यह स्थिर हो सकता है।

@timneutkens @Janpot

मैंने नवीनतम अगली कैनरी (9.4.5-कैनरी.27) की कोशिश की, लेकिन जब मैं test पेज बनाता हूं और मैं www.example/test/ तक पहुंचता हूं तो यह www.example/test रीडायरेक्ट हो जाता है
मुझे लगता है कि दोनों मामलों के लिए व्यवहार समान होना चाहिए।

जब www.example/test/ तक पहुंचें तो इसे www.example/test/ पर रहना चाहिए।
जब www.example/test तक पहुंच हो तो इसे www.example/test पर रहना चाहिए।
मैं इसे Nuxt.js पर परीक्षण करता हूं, यह वही व्यवहार करता है जो मैं ऊपर वर्णित करता हूं।

मुझे लगता है कि दोनों मामलों के लिए व्यवहार समान होना चाहिए।

रीडायरेक्ट का कारण यह सुनिश्चित करना है कि खोज इंजन डुप्लिकेट सामग्री नहीं देखते हैं। आपका सटीक उपयोग-मामला क्या है?

मुझे नहीं लगता कि यह एक बंद मुद्दा क्यों है अगर इसे अभी तक एक स्थिर रिलीज में विलय नहीं किया गया है। अगर मैं सही ढंग से समझ गया तो यह अभी के लिए कैनरी रिलीज में ही तय है, है ना?

जब उनका संबद्ध पुल अनुरोध भूमि पर आता है, तो समस्याएँ बंद हो जाती हैं, क्योंकि वे कैनरी पर तत्काल उपयोग के लिए उपलब्ध हैं। यदि आपको इस सुविधा की आवश्यकता है, तो कृपया कैनरी चैनल में अपग्रेड करें।

बढ़िया है। धन्यवाद, @ टाइमर!

@Janpot मैंने देखा कि https://github.com/issues/ और https://github.com/issues बिना रीडायरेक्ट के समान व्यवहार तक पहुंच सकते हैं।

https://twitter.com/explore/ और https://twitter.com/explore , यह भी।

अगर इसे सर्च इंजन में कोई समस्या है, तो जीथब और ट्विटर ने इसे ठीक क्यों नहीं किया?
मुझे लगता है कि यह किसी भी वेबसाइट के लिए डिफ़ॉल्ट व्यवहार है।

कोई विशिष्ट उपयोग-मामला नहीं है, यह सिर्फ मेरी राय है कि इसे इस तरह से काम करना चाहिए।

अगर इसे सर्च इंजन में कोई समस्या है, तो जीथब और ट्विटर ने इसे ठीक क्यों नहीं किया?

@armspkt यह कोई समस्या नहीं है क्योंकि इसे हल करने के कई तरीके हैं। उदाहरण के लिए ट्विटर <link rel="canonical"> विशेषता का उपयोग खोज बॉट को यह बताने के लिए करता है कि उन्हें कौन सा पृष्ठ क्रॉल करना चाहिए और अन्य संस्करणों को डुप्लिकेट के रूप में चिह्नित किया जाना चाहिए।

तो रीडायरेक्ट आपकी वेबसाइट पर SEO करने का एक व्यवहार्य तरीका है। आप यहां अधिक जानकारी पढ़ सकते हैं।

@ziserman अगर हमारे पास इसे हल करने के कई तरीके हैं, तो हमें उपयोगकर्ता अनुभव के लिए उसी यूआरएल को रीडायरेक्ट किए बिना रखना चाहिए।

@Janpot https://github.com/nuxt-community/nuxt-i18n/issues/422

Nuxtjs के पास चुनने के लिए कई विकल्प हैं (अपरिभाषित, सत्य, असत्य)

क्या नेक्स्टज के पास भी चुनने के लिए सर्वरल विकल्प होने चाहिए?

रीडायरेक्ट का कारण यह सुनिश्चित करना है कि खोज इंजन डुप्लिकेट सामग्री नहीं देखते हैं। आपका सटीक उपयोग-मामला क्या है?

@Janpot हमारे एपीआई में कई जगहों पर पिछली स्लैश हैं। नवीनतम रिलीज़ बैकएंड पर 404 की संख्या बढ़ाता है क्योंकि पिछली स्लैश वाले यूआरएल (/ एपीआई/टेस्ट/ ->/एपीआई/टेस्ट) मेल नहीं खाते हैं

मुझे नहीं पता कि यह सभी के लिए काम करेगा या नहीं, लेकिन मुझे यह समाधान मिल गया है जो मेरे लिए काम करता है। इसे _app.js फ़ाइल में डालें।

static async getInitialProps(ctx) {
    const appProps = await App.getInitialProps(ctx);

    // Remove trailing slash
    const path = ctx.router.asPath,
            res = ctx.ctx.res;

    if (path.length > 1 && /\/$/.test(path)) {
        res.writeHead(301, {Location: path.slice(0, -1)})
        res.end();
    }

    return {...appProps};
}

@mlbonniec मैंने आपकी टिप्पणी को छोटा कर दिया है क्योंकि यह Next.js ऐप में गंभीर प्रदर्शन प्रतिगमन का कारण बनता है।

नवीनतम next@canary संस्करण इस बग को ठीक करता है, कृपया इसके बजाय अपग्रेड करें!

@mlbonniec मैंने आपकी टिप्पणी को छोटा कर दिया है क्योंकि यह Next.js ऐप में गंभीर प्रदर्शन प्रतिगमन का कारण बनता है।

नवीनतम next@canary संस्करण इस बग को ठीक करता है, कृपया इसके बजाय अपग्रेड करें!

कोई दिक्कत नहीं है!
हालाँकि, मैंने पहले अपडेट किया था, और इससे समस्या का समाधान नहीं हुआ।
npm update

अगर नवीनतम नेक्स्ट.जेएस कैनरी आपके लिए बग को ठीक नहीं करता है, तो कृपया एक नया मुद्दा खोलें ताकि हम एक नज़र डाल सकें। 🙏

त्वरित प्रश्न, next export प्रोजेक्ट इस परिवर्तन को कैसे संभालेंगे? अनुगामी स्लैश के लिए प्रत्येक पृष्ठ के लिए एक बिल्कुल नया पृष्ठ बनाकर? मुझे नहीं लगता कि एक निर्यात किया गया ऐप HTTP रीडायरेक्ट (या फिर से लिखता है) निर्दिष्ट कर सकता है।

जो प्रोजेक्ट next export का उपयोग करते हैं, उनके सभी <Link /> क्लाइंट-साइड पर सही ढंग से अपडेट किए जाएंगे, लेकिन सर्वर-साइड रीडायरेक्ट के लिए मैन्युअल कॉन्फ़िगरेशन की आवश्यकता होगी। सर्वर रहित लक्ष्य या next start साथ परिनियोजित प्रोजेक्ट इन सेटिंग्स को स्वचालित रूप से कॉन्फ़िगर करेंगे।

@Timer एक बार जब यह पूर्ण रिलीज़ तक पहुँच जाता है, तो क्या हमें अभी भी प्रयोगात्मक विकल्प का उपयोग करने की आवश्यकता होगी?

@Timer एक बार जब यह पूर्ण रिलीज़ तक पहुँच जाता है, तो क्या हमें अभी भी प्रयोगात्मक विकल्प का उपयोग करने की आवश्यकता होगी?

नहीं, जैसा है वैसा ही उपलब्ध होगा।

मुझे लगता है कि trailingSlash विकल्प next export लिए काम नहीं करेगा? /page/ को /page (या इसके विपरीत) में रीडायरेक्ट करने का सबसे अच्छा तरीका क्या है, कहें, जीथब पेज?

मुझे लगता है कि trailingSlash विकल्प next export लिए काम नहीं करेगा? /page/ को /page (या इसके विपरीत) में रीडायरेक्ट करने का सबसे अच्छा तरीका क्या है, कहें, जीथब पेज?

जहां तक ​​​​मुझे पता है जीथब पेज में रीडायरेक्ट फीचर नहीं है। यह vercel.com पर बॉक्स से बाहर काम करता है, हालांकि यह हॉबी प्रोजेक्ट्स के लिए भी मुफ़्त है (जैसे जीथब पेज है)।

जो प्रोजेक्ट next export का उपयोग करते हैं, उनके सभी <Link /> क्लाइंट-साइड पर सही ढंग से अपडेट किए जाएंगे, लेकिन सर्वर-साइड रीडायरेक्ट के लिए मैन्युअल कॉन्फ़िगरेशन की आवश्यकता होगी। सर्वर रहित लक्ष्य या next start साथ परिनियोजित प्रोजेक्ट इन सेटिंग्स को स्वचालित रूप से कॉन्फ़िगर करेंगे।

हाय @ टाइमर क्या आप और समझा सकते हैं? मैं मैन्युअल रूप से कैसे कॉन्फ़िगर कर सकता हूं? तो यहाँ मेरी स्थिति है। मैं अपनी वेबसाइट पर next-i18next उपयोग करता हूं। मेरे द्वारा next build && next export साथ परिनियोजित करने के बाद, सभी आंतरिक लिंक काम करते हैं लेकिन जब मैन्युअल रूप से URL दर्ज करते हैं, तो उनमें से कोई भी काम नहीं करता है और 404 त्रुटि का कारण बनता है। यहां से मैंने trailingSlash:true का उपयोग करने का निर्णय लिया और इसलिए मैन्युअल रूप से दर्ज करें /pricing अब काम करेगा लेकिन /zh/pricing 404 त्रुटियों की ओर जाता है।