HTTP/HTML/browser
Talk about the HTML5 Drag API
Reference answer
- Dragstart: The event body is the element being dragged and is triggered when the element is being dragged and dropped.
- Darg: The event body is the element being dragged and fired while the element is being dragged and dropped.
- Dragenter: The event body is the target element, fired when an element is dragged into an element.
- Dragover: The event body is the target element that is fired when it is dragged and moved within an element.
- Dragleave: The event body is the target element and is triggered when the drag-and-drop element is removed from the target element.
- Drop: The event body is the target element and is fired when the target element fully accepts the dragged element.
- Dragend: The event body is the element being dragged and fired at the end of the entire drag-and-drop operation
400 and common status code such as 401 and 403 Status code
Reference answer
Just list the most common ones
400 Status code: The request is invalid
Cause: The field name and type of the data submitted by the front-end are inconsistent with that of the background entity
The data the front end submits to the back end should be a JSON string, but the front end does not convert the object json.stringify to a string.
Solutions:
Compare the field names for consistency
Serialize the obj object through json.stringify
401 Status Code:
The current request requires user authentication
403 Status Code:
The server has received the request, but refuses to execute it
A status code of 404
The requested page does not exist
A status code of 503
Service unavailable
The reason why fetch sent two requests
Reference answer
When the fetch sends a POST request, it always sends two times, the first status code is 204, and the second one is successful. The reason is simple, because when you use the FETCH’s POST request, the fetch sends an Options request the first time, asking the server if it supports the modified headers, and then sends the real request the second time if the server does.
Cookie, sessionStorage, localStorage
Reference answer
Common: both are saved in the browser and are of the same origin
Cookie: Cookie data is always carried (even if it is not needed) in a same-origin HTTP request, i.e. cookies are passed back and forth between the browser and the server. However, sessionStorage and localStorage do not automatically send data to the server and only store data locally. Cookie data also has the concept of path, which can limit cookies to belong to a certain path and store them in a small size of 4K or so. (Key: it can be passed back and forth between browser and server, with small storage capacity, only about 4K)
SessionStorage: only valid until the current browser window closed, naturally also cannot be persistent, localStorage: always valid, the window or browser closed is always saved, therefore used as persistent data; Cookies only remain valid until the set cookie expiration time, even if the window or browser is closed. (Key: it is a callback process itself, and disappears after closing the browser. Session is a callback. If the page is different, even if the same page is opened twice, it is regarded as the same callback.)
LocalStorage: localStorage is shared in all origin Windows; Cookies are also shared across all the same origin Windows. (Key: Same-origin Windows will be shared and will not be invalid, regardless of whether the window or browser is closed or not.)
Here’s a reminder of what cookies do:
Save the user login status. For example, storing the user ID in a cookie so that the user does not need to log in again the next time they visit the page is a feature that is now available in many forums and communities. Cookies can also set the expiration time, when the time limit is exceeded, the cookie will automatically disappear. As a result, the system can often prompt users for how long they want to keep their login status: common options are one month, three months, a year, and so on.
Track user behavior. A weather website, for example, can display local weather conditions based on the region selected by the user. If it is cumbersome to choose the location every time, it will appear very humanized after using cookies. The system can remember the area visited last time, and when opening the page next time, it will automatically display the weather situation in the area where the user was last time. Because everything is done in the background, such pages are very easy to customize as if they were customized for a particular user. If the site provides the ability to skin or change the layout, cookies can be used to record the user’s options, such as background color, resolution, etc. When the user visits the interface next time, the interface style of the last visit can still be saved.
Talk about Web workers
Reference answer
In AN HTML page, if the state of the page is not corresponding when the script is executed, the page does not become corresponding until after the script is executed. Web workers are js running in the background, independent of other scripts, and do not affect your page performance. The result is passed back to the main thread via postMessage. This will not block the main thread during complex operations.
How to create web Workers
Check browser support for Web workers
Create Web worker files (js, postback functions, etc.)
Create a Web Worker object
Understanding of HTML semantic tags
Reference answer
HTML5 semantic tags refer to the right tags that contain the right content, are well structured and easy to read, such as nav, article, header, footer, etc.
What is an iframe? What are the disadvantages?
Reference answer
Definition: The iframe element creates an inline frame that contains another document
Prompt: You can place prompt text in between to alert certain browsers that do not support iframe
Disadvantages:
Blocks the onLoad event on the main page
Search engines can’t read these pages, which is bad for SEO
Iframe and the home page share the connection pool, and browsers have restrictions on the same area, which can affect performance.
Doctype? How to distinguish strict mode from promiscuous mode? What do they mean?
Reference answer
Doctype is declared at the beginning of the document and tells the browser how to render the page. There are two modes, strict mode and hybrid mode.
Strict mode typesetting and JS mode of operation are run to the highest standards supported by the browser.
Promiscuous mode, backward compatibility, emulates older browsers and prevents browsers from not being compatible with pages.
How do cookies protect against XSS attacks
Reference answer
XSS (cross-site scripting attacks) is when an attacker emashes javascript scripts in the returned HTML. To mitigate these attacks, a set-cookie is configured in the HTTP header in response:
Httponly – This property prevents XSS, which prevents javascript scripts from accessing cookies.
Secure – This property tells the browser to send cookies only if the request is HTTPS (with SSL encryption).
The result should be: set-cookie =….
The difference between cookies and sessions
Refer to the answer
- Cookie data is stored on the client’s browser and session data is stored on the server.
- Cookies are not very secure. Others can analyze cookies stored locally and cheat cookies
- Sessions should be used for security reasons.
- Sessions are stored on the server for a certain amount of time. When the number of visits increases, it takes a lot of performance out of your server
- Cookies should be used to alleviate server performance.
- A single cookie can hold no more than 4K of data, and many browsers limit the number of cookies a site can hold to 20.
HTTP is a stateless protocol, so the biggest use of cookies is to store session ids that uniquely identify users.
In a sentence
Refer to the answer
It uses URLS to locate resources and HTTP to describe operations.
Click has 300ms latency on ios, why and how to solve it?
Refer to the answer
(1) Bold, disable zoom
<meta name="viewport" content="width=device-width, user-scalable=no">
Copy the code(2) Using FastClick, its principle is: after detecting the Touchend event, immediately start to simulate the Click event, and the browser 300 milliseconds after the actual event to block
AddEventListener parameters
Refer to the answer
addEventListener(event, function, useCapture)
Event Specifies the event name.
Function specifies the function to execute when the event is fired.
UseCapture specifies whether the event is executed in the capture or bubble phase. (false- bubble, true- capture)
Common HTTP request headers
Refer to the answer
| agreement | instructions |
|---|---|
| Accept | Acceptable response Content Types |
| Accept-Charset | Acceptable character set |
| Accept-Encoding | The encoding of acceptable response content. |
| Accept-Language | List of acceptable response content languages. |
| Accept-Datetime | An acceptable time-dependent version of the response content |
| Authorization | Authentication information of the resource to be authenticated in HTTP |
| Cache-Control | Used to specify whether caching is used in the current request/reply. |
| Connection | The type of connection that the client (browser) wants to use preferentially |
| Cookie | An HTTP Cookie Set by the previous server via set-cooki (e see below) |
| Content-Length | The length of the request body in base 8 |
| Content-MD5 | The binary MD5 hash value (digitally signed) of the content of the request body, the result encoded in Base64 |
| Content-Type | MIME type of the request body (for POST and PUT requests) |
| Date | The date and time the message is sent (in the “HTTP date “format defined in RFC 7231) |
| To send) | |
| Expect | Indicates that the client is asking the server to perform a specific behavior |
| From | The email address of the user who initiated this request |
| Host | Indicates the domain name of the server and the port number monitored by the server. If the requested port is the standard port (80) of the corresponding service, the port number can be omitted. |
| If-Match | The operation is performed only when the entity provided by the client matches the entity on the server. In methods such as PUT, a resource is updated only if it has not been modified since the last update by a slave user. |
| If-Modified-Since | 304 unmodified is allowed if the corresponding resource has not been modified |
| If-None-Match | Allows 304 NotModified to be returned if the corresponding content has not been modified, referring to the entity flag of the Hypertext Transfer protocol |
| If-Range | If the entity has not been modified, the missing one or more parts are returned. Otherwise, return the entire new entity |
| If-Unmodified-Since | A response is sent only if the entity has not been modified since a certain time. |
| Max-Forwards | Limits the number of times the message can be forwarded by the proxy and gateway. |
| Origin | Initiate a request for cross-domain resource sharing (this request requires the server to include an Access-Control-Allow-Origin header in the response to indicate the source that Access Control allows). |
| Pragma | Implementation-specific, these fields can be generated at any time in the request/response chain. |
| Proxy-Authorization | Authentication information used to authenticate the agent. |
| Range | Represents a request for a portion of an entity, byte offset starting at 0. |
| Referer | Represents the previous page visited by the browser, which can be considered to have been brought to the current page by links from previous visits. “Referer” is actually the word “Referrer,” but the RFC misspelled the standard and used it instead. |
| TE | The way the browser is expected to accept the transport is encoded: the response protocol header can be used |
| Transfer-Encoding | (you could also use “Trailers” to say that the browser wanted to receive some additional fields after the last 0 block.) |
| User-Agent | The browser identity string |
| Upgrade | Requires that the server be upgraded to a higher version protocol. |
| Via | Tell the server which agent made the request. |
| Warning | A general warning that there may be an error in the entity content body. |
Strong cache, negotiated cache
Refer to the answer
| The title | Form of resource acquisition | Status code | Send the request to the server |
|---|---|---|---|
| Strong cache | From the slow access | 200 (from cache) | No, cache access directly |
| Negotiate the cache | From the slow access | 304 (not modified) | If yes, the server tells you whether the cache is available |
Strong cache fields include Expires and cache-Control. Cache-control takes precedence over Expires if both exist.
The negotiation cache fields are last-modified/if-modified-since, Etag/ if-none-match
When to use strong cache or negotiated cache
Refer to the answer
Since the resource on the server is not fixed all the time, most of the time it is updated. If we access the local cache, then for the user, it is equivalent to the resource is not updated, and the user sees the old resource. Therefore, we want to request new resources when the browser updates the resources on the server, and use the local cache when there is no update to minimize the waste of resources caused by network requests.
Graph TD browser request --> Cached --> Expired? -- -- - > the Etag? ; Is it expired? -- No --> read from cache --> render; Etag? -- Yes --> Send request to web server with if-Modified-match -- server decision -->200/304? --304--> Read from cache --> render; Etag - no - > last-modified? -- Yes --> send request to server with if-modified-since -- server decision -->200/304? --200--> Request response cache negotiation --> Render; Last-modified? -- No --> Send a request to the Web server --> Request response cache negotiation --> Render