Introduction

In virtually every modern web and mobile application, the ability to upload files — such as images, documents, videos, or spreadsheets — is a critical feature. Whether it’s submitting a resume, uploading product images, or syncing a document to the cloud, file upload functionality is a core component of user interaction and data storage workflows.

This guide provides a comprehensive overview of file upload systems, including what file uploading is, major use cases, how it works under the hood, architectural components, a typical workflow, and a step-by-step implementation guide.

What is File Upload?

File upload refers to the process of transferring files from a local device (client) to a remote server or cloud storage system, usually via an HTTP-based interface like a web form, REST API, or application logic.

In simple terms, a file upload allows a user to select a file and submit it to a server where it can be stored, processed, or distributed further.

Types of file uploads:

• Single file upload
• Multiple file upload
• Chunked upload (for large files)
• Drag-and-drop upload interfaces
• Background or asynchronous uploads

Major Use Cases of File Upload

1. User-Generated Content

• Uploading profile pictures, videos, resumes, posts.
• Used in social media platforms, job portals, forums.

2. E-Commerce & Product Management

• Uploading product images, descriptions, inventory files.
• Often seen in seller dashboards or admin panels.

3. Document Submission Systems

• Submission of assignments, contracts, identification documents.
• Used in education, legal, HR, and government systems.

4. Media and Content Platforms

• Uploading photos, music, video content.
• Includes support for thumbnails, previews, and metadata.

5. Enterprise Applications

• Uploading reports, logs, spreadsheets for processing or analytics.
• Common in CRMs, ERPs, and internal portals.

6. Cloud Storage and Backup

• Uploading files for storage on cloud platforms like Google Drive, Dropbox, AWS S3.

How File Upload Works: Architecture and Components

The architecture behind file uploads involves several components that work together to receive, store, and manage uploaded files.

1. Frontend (Client-Side)

The user interface where users select files to upload, typically via:

• <input type="file" /> in HTML
• Drag-and-drop areas (using JavaScript APIs)
• Form submission or Ajax-based asynchronous uploads

2. HTTP Protocol

File uploads are typically sent over HTTP using the multipart/form-data encoding type, which packages file data and metadata in a single request.

3. Backend Server

The backend handles:

• Parsing the file from the HTTP request
• Validating file type, size, and metadata
• Temporarily storing the file
• Saving to persistent storage (filesystem, database, or cloud)

Common backend technologies:

• Node.js (with Express + Multer)
• Python (with Flask or Django)
• Java (Spring Boot)
• PHP (Laravel or native)

4. Storage Layer

Uploaded files are saved either:

• On the server’s local filesystem (for small apps)
• In a cloud storage service (e.g., AWS S3, Azure Blob Storage, Google Cloud Storage)

5. Database (Optional)

Metadata (filename, path, uploader ID, timestamp) may be stored in a database for retrieval, indexing, or linking.

6. Security Layer

Important security features include:

• File type validation (MIME type)
• Antivirus scanning
• File size restrictions
• Authentication and authorization

Basic Workflow of File Upload

The file upload process usually follows these steps:

1. User Selects File
   The user chooses one or more files using a file input field or drag-and-drop.
2. File Data is Packaged
   Files are submitted in a form using the multipart/form-data encoding.
3. Frontend Sends Request
   The file is sent to the backend via HTTP POST or PUT request.
4. Backend Parses and Validates
   The server extracts file data, checks file size/type, and may rename or hash it.
5. File is Saved
   The file is written to a location on the server or uploaded to cloud storage.
6. Database Entry is Created (Optional)
   Metadata is stored (e.g., file name, URL, user, timestamp).
7. Server Responds
   A response (success/failure + metadata or URL) is returned to the client.
8. File Is Available
   The file can be accessed via a URL or internal system endpoint.

Step-by-Step Getting Started Guide for File Upload

Here’s a simple example using Python Flask and HTML.

Step 1: Setup Flask Environment

Install Flask:

pip install flask

Step 2: Create Backend App

# app.py
from flask import Flask, request, redirect, url_for
import os

app = Flask(__name__)
UPLOAD_FOLDER = './uploads'
app.config['UPLOAD_FOLDER'] = UPLOAD_FOLDER

@app.route('/')
def upload_form():
    return '''
        <form method="post" action="/upload" enctype="multipart/form-data">
            <input type="file" name="file">
            <input type="submit">
        </form>
    '''

@app.route('/upload', methods=['POST'])
def upload_file():
    file = request.files['file']
    if file:
        filepath = os.path.join(app.config['UPLOAD_FOLDER'], file.filename)
        file.save(filepath)
        return f'File uploaded to {filepath}'

if __name__ == '__main__':
    os.makedirs(UPLOAD_FOLDER, exist_ok=True)
    app.run(debug=True)

Step 3: Run the Server

python app.py

Visit http://127.0.0.1:5000 in a browser and upload a file.

Step 4: Secure and Expand

• Add checks for allowed file types:

ALLOWED_EXTENSIONS = {'png', 'jpg', 'pdf', 'txt'}
def allowed_file(filename):
    return '.' in filename and filename.rsplit('.', 1)[1].lower() in ALLOWED_EXTENSIONS

• Expand to use cloud storage (e.g., AWS S3 with boto3)
• Add authentication to restrict access

Best Practices

• Always validate file type and size on both client and server.
• Sanitize filenames to prevent directory traversal attacks.
• Use hashed or UUID filenames to avoid overwrites.
• Store files outside the web root or behind signed URLs.
• Consider chunked upload for large files.
• Use background workers (Celery, Sidekiq) for processing heavy uploads.

The post Mastering File Uploads: A Complete Guide to Uploading Files in Modern Applications appeared first on scmGalaxy.

What Are Cookies?

Cookies are small text files that web servers send to a user’s web browser, which stores them on the client’s device. These files contain data that help websites remember information about users, such as login status, preferences, or tracking identifiers.

Cookies were introduced in the early 1990s to address the challenge posed by the HTTP protocol’s statelessness — meaning that each request to a server is independent and does not inherently carry information about previous interactions. Cookies allow websites to “remember” users and their interactions across sessions.

Each cookie consists of key-value pairs and a set of metadata that define the cookie’s scope, lifespan, and security properties. The browser automatically includes relevant cookies in subsequent HTTP requests to the appropriate domains, enabling servers to maintain a continuous user experience.

Major Use Cases of Cookies

Cookies are vital across many web application domains due to their ability to persist state and track information. Below are key use cases:

1. Session Management

Cookies enable websites to identify returning users and maintain session continuity without requiring users to authenticate on every page load. For example, after logging in, a session cookie keeps a user logged in until they log out or the session expires.

2. User Preferences and Personalization

Cookies store user settings such as language preferences, theme choices, or layout configurations. When a user revisits, the site can retrieve these preferences and tailor the interface accordingly.

3. Shopping Cart Persistence

E-commerce websites leverage cookies to remember products added to a user’s cart even if the browser is closed and reopened before checkout, enhancing the shopping experience.

4. Tracking and Analytics

Cookies collect data on user behavior, page visits, and navigation paths. Analytics platforms use cookies to generate insights about website performance and user engagement. Advertising networks use third-party cookies to track users across sites for targeted ads.

5. Security

Cookies help secure web applications by storing tokens or flags used in authentication workflows, CSRF protection, and managing user permissions.

6. Legal Compliance

Cookies assist in storing consent information, ensuring compliance with data protection regulations like the General Data Protection Regulation (GDPR) and California Consumer Privacy Act (CCPA).

How Cookies Work Along with Architecture

Cookies operate at the intersection of HTTP protocol, client (browser) storage, and server-side application logic. The architecture supporting cookie functionality includes several components:

1. HTTP Headers and Communication

• When a client sends a request to a server, it includes a Cookie header containing cookies relevant to the request URL’s domain and path.
• The server can send back one or more Set-Cookie headers in its response to instruct the browser to store new cookies or update existing ones.

Example HTTP response header:

Set-Cookie: sessionId=abc123; Expires=Wed, 09 Jun 2026 10:18:14 GMT; Path=/; Secure; HttpOnly; SameSite=Strict

2. Browser Cookie Storage

• Browsers maintain a “cookie jar” storing cookies by domain and path.
• They enforce scoping rules, ensuring cookies are only sent to appropriate URLs.
• Cookies are stored on disk or in memory depending on persistence.

3. Cookie Attributes and Their Impact

• Domain: Restricts the domains to which the cookie will be sent. Cookies set for example.com are sent to sub.example.com but not to otherdomain.com.
• Path: Restricts the URL paths on the domain for which the cookie is valid.
• Expires/Max-Age: Defines when a cookie will be deleted. Session cookies expire when the browser closes; persistent cookies survive beyond sessions.
• Secure: Ensures cookies are only sent over HTTPS connections.
• HttpOnly: Prevents client-side JavaScript from accessing cookies, mitigating some XSS attacks.
• SameSite: Controls cross-site cookie sharing to prevent CSRF and privacy leaks. Values include Strict, Lax, or None.

4. Server-Side Handling

• Servers read cookies from incoming requests and use their data to maintain sessions, authenticate users, or track state.
• Servers can update or delete cookies by sending updated Set-Cookie headers.

5. Third-Party Cookies

• These are cookies set by domains other than the one shown in the browser’s address bar, typically used by advertisers or analytics services.
• Modern browsers are increasingly restricting third-party cookies due to privacy concerns.

Detailed Workflow of Cookies

1. Initial Visit

• User visits a website; the browser sends a request without cookies.

2. Server Response with Cookies

• Server responds with Set-Cookie headers to establish sessions or preferences.

3. Browser Stores Cookies

• The browser saves cookies respecting domain, path, security attributes.

4. Subsequent Requests

• Browser automatically includes relevant cookies in HTTP requests for that domain/path.

5. Server Processes Cookies

• Server uses cookies to authenticate the user, retrieve session data, or customize the response.

6. Cookie Updates

• Server can update cookies by sending new Set-Cookie headers with modified values or expiration.

7. Cookie Expiration or Deletion

• Cookies expire naturally after their expiry time or are deleted by explicit instructions or user actions.

Step-by-Step Getting Started Guide for Cookies

Step 1: Understand Cookie Fundamentals

Familiarize yourself with cookie components — name, value, domain, path, expiry, and security flags.

Step 2: Setting Cookies from the Server

Example: Node.js Express

res.cookie('userId', '12345', {
  maxAge: 24 * 60 * 60 * 1000, // 1 day
  httpOnly: true,
  secure: true,
  sameSite: 'Strict',
  path: '/'
});

Step 3: Reading Cookies on Server

Using the cookie-parser middleware:

const userId = req.cookies.userId;
console.log(`User ID from cookie: ${userId}`);

Step 4: Creating Cookies with JavaScript

document.cookie = "theme=dark; max-age=3600; path=/";

Step 5: Deleting Cookies

Set expiration date in the past:

document.cookie = "theme=; expires=Thu, 01 Jan 1970 00:00:00 UTC; path=/;";

Step 6: Implement Security Best Practices

• Always set HttpOnly and Secure flags where possible.
• Use SameSite attributes to reduce CSRF vulnerabilities.
• Avoid storing sensitive information directly in cookies.

Step 7: Respect Privacy Regulations

• Implement consent banners.
• Provide users with options to manage cookie preferences.
• Document cookie usage in privacy policies.

Advanced Topics and Considerations

1. Cookie Size and Limits

• Most browsers limit individual cookie size to 4KB.
• There is a per-domain cookie limit (around 20–50 cookies).
• Exceeding limits causes older cookies to be evicted.

2. Third-Party Cookie Restrictions

• Browsers increasingly block or restrict third-party cookies.
• Alternatives include localStorage, IndexedDB, or server-side sessions.

3. Alternatives to Cookies

• Web Storage API (localStorage, sessionStorage) for client-side storage.
• JWT tokens for stateless authentication.

4. Cross-Origin Resource Sharing (CORS) and Cookies

• Cookies require careful configuration of CORS headers and credentials policies to work across domains.

The post Understanding Cookies: Concepts, Use Cases, Architecture and Getting Started appeared first on scmGalaxy.

What is a URL?

A Uniform Resource Locator (URL) is a standardized address used to locate resources on the internet. It is a subset of the broader concept called URI (Uniform Resource Identifier), specifically identifying the means to retrieve a resource by describing its location and the protocol to access it.

A URL acts like a digital address or coordinate that points to a particular resource on the web. Without URLs, users would have no direct way to access websites, files, images, videos, or any online service.

Components of a URL

A URL is composed of several distinct parts, each serving a specific role:

• Scheme/Protocol: This specifies the protocol used to access the resource, such as http, https, ftp, mailto, or file. For web browsing, http and https are the most common.
• Host/Domain: The domain name (e.g., www.example.com) or IP address of the server hosting the resource.
• Port (optional): The network port number used to connect to the server. By default, HTTP uses port 80 and HTTPS uses port 443.
• Path: Specifies the exact location or file on the server (e.g., /folder/page.html).
• Query String (optional): Parameters that provide additional data to the server, often for dynamic content generation (e.g., ?search=books&sort=asc).
• Fragment (optional): Refers to a subsection within the resource (e.g., #section2), often used for navigation inside long web pages.

Example URL:
https://www.example.com:443/products/item?category=books#reviews

Major Use Cases of URLs

URLs are essential in modern internet usage and serve many purposes:

1. Accessing Websites and Web Pages
   The most common use of URLs is to access websites. Every webpage, image, or video on the web has a unique URL. When users type a URL in their browser, it directs the browser to fetch that resource.
2. Linking and Navigation
   URLs enable hyperlinking, which allows users to navigate seamlessly across different pages, websites, and resources. Hyperlinks embedded in text or buttons use URLs to point to another location.
3. Accessing APIs and Web Services
   In software development, URLs are used to access RESTful APIs and web services. These URLs point to endpoints where clients can send requests and receive structured data like JSON or XML.
4. File Transfers
   Protocols like FTP use URLs to locate and transfer files between client and server.
5. Sharing Content
   URLs allow easy sharing of content through social media, emails, and messaging apps. Shortened URLs are often used for convenience.
6. Bookmarking and Caching
   URLs enable users to save favorite resources and allow browsers to cache content for faster future access.
7. Tracking and Analytics
   Query parameters in URLs can track user behavior, campaign effectiveness, and source attribution for marketing purposes.

How URL Works Along with Architecture

Understanding how URLs work requires insight into the broader architecture of the web. The web is a client-server architecture based on protocols like HTTP and HTTPS. Here’s how the URL fits into the system:

Key Components in URL Architecture

• Client (User Agent)
  This is typically a web browser or any software that initiates requests. When a URL is entered, the client parses it to understand where and how to retrieve the resource.
• DNS (Domain Name System)
  DNS translates the human-readable domain name from the URL into a machine-readable IP address. This step is crucial because the internet uses IP addresses to route requests.
• Internet
  The underlying network infrastructure routes data packets between the client and server.
• Web Server
  This server listens on a specific IP and port and hosts the requested resource (website, file, or service). It processes incoming requests and sends back responses.
• Protocols (HTTP/HTTPS)
  Define the communication rules between client and server, including request methods (GET, POST), headers, and status codes.

Detailed Process Flow

1. User Enters URL
   The user types a URL in the browser or clicks a hyperlink.
2. URL Parsing
   The browser parses the URL into its components (scheme, host, path, etc.).
3. DNS Lookup
   The browser queries a DNS server to convert the domain name into an IP address.
4. Establish Connection
   The browser establishes a TCP connection to the web server at the resolved IP and port. For HTTPS, a TLS handshake ensures a secure connection.
5. Send HTTP Request
   The browser sends an HTTP request message to the server, typically a GET request asking for the resource specified in the URL.
6. Server Processes Request
   The server locates the resource and prepares a response.
7. Server Sends Response
   The server sends an HTTP response with status codes (e.g., 200 OK, 404 Not Found) and the requested data.
8. Browser Renders Content
   The browser receives the data and renders the webpage or resource to the user.

Basic Workflow of URL

The workflow of using a URL can be broken down into these essential steps:

1. Input & Parsing: User inputs the URL; the browser breaks it into understandable parts.
2. DNS Resolution: Converts domain name into an IP address using DNS.
3. Connection Setup: Opens a network connection with the server.
4. Request Formation: The browser builds the HTTP request based on the URL path and method.
5. Request Transmission: Request is sent to the server.
6. Server Response: Server processes the request and responds.
7. Response Reception: Browser receives the data.
8. Rendering: Content is displayed to the user.
9. Interaction: User interacts with the content, potentially triggering new URL requests.

Step-by-Step Getting Started Guide for URL

Whether you’re a user, student, or developer, here is a guide to get started with understanding and using URLs effectively:

Step 1: Understanding URL Components

Start by dissecting any URL you come across. Identify the protocol (e.g., https), the domain name (e.g., www.google.com), the path (e.g., /search), query parameters (e.g., ?q=openai), and any fragment identifiers.

Step 2: Using a Web Browser

Open any web browser (Chrome, Firefox, Safari) and enter a URL into the address bar. Observe how the page loads. Try changing parts of the URL to see how it affects the content.

Step 3: DNS Lookup Exploration

Use command-line tools like nslookup or dig to see how the domain name is resolved to an IP address. For example, running nslookup www.example.com shows the server IP.

Step 4: Try Different Protocols

Experiment with different URL schemes like ftp:// or mailto: to see how browsers or applications respond to different protocols.

Step 5: Modify Query Strings

Add or change query parameters in URLs (e.g., ?page=2&sort=asc) to observe how dynamic content changes on websites.

Step 6: Use URL in Development

In programming or web development, URLs are vital for making API requests, linking resources, and configuring routing. Try calling a simple public API with a URL in tools like Postman or your code.

Step 7: Security Awareness

Understand the difference between http and https. Always prefer HTTPS URLs for secure communication that encrypts data in transit.

The post Comprehensive Guide to URLs: Definition, Use Cases, Architecture, and Getting Started appeared first on scmGalaxy.

Cookies are little text files that websites save on the user’s device (such as a computer or mobile device) when the user visits the website. These files include information that the website may download and utilize the next time the visitor visits the site.

HTTP cookies are required for modern Internet use, yet they compromise your privacy. HTTP cookies, which are a required aspect of online browsing, assist web developers in providing you with more personalized, easy website visits. Websites may remember you, your website logins, shopping carts, and other information via cookies. They may, however, be a goldmine of private information for crooks to snoop on.

Different types of cookies – Magic Cookies and HTTP Cookies

Magic cookies :- The term “magic cookies” originated in the early days of computers and describes data packets that are delivered and received unchanged. This is frequently used to enter into computer databases, such a company’s internal network. The term “cookie” as we know it today predates this concept.

HTTP cookies :- HTTP cookies are a modified form of the “magic cookie” designed for web browsing. The “magic cookie” inspired web browser creator Lou Montulli in 1994. When he assisted a website for online shopping in repairing its overburdened servers, he duplicated this idea for browsers.

What Are Cookies Used For?

Websites utilize HTTP cookies to improve the user experience. Without cookies, you would have to log back in each time you left a website or, if you accidently closed the browser, rebuild your shopping cart. making cookies a crucial component of using the internet.

Session management :- Transient cookies and per-session cookies are other names for session cookies. While a person is browsing a website, session cookies save data. Once the user ends the session, these cookies are removed.

Persistent cookie :- Cookies that are persistent are kept for a certain period of time. Until they are erased or they expire, these cookies stay on your device. Because they are used to gather user data including browsing patterns and preferences, persistent cookies are also known as tracking cookies.

First-party and third-party cookies :- Cookies that are set by websites that users visit directly are known as first-party cookies. These cookies typically store data relevant to or related with the website, such as user preferences or location.
Cookies that are associated with third-party content, such as embedded videos, advertisements, web banners, and scripts, are referred to as third-party cookies. Third-party cookies are frequently used by advertisers to monitor user behaviour.

Tracking :- Shopping sites use cookies to keep track of the items that users have previously viewed, allowing the sites to propose more things that they may be interested in and store products in their shopping carts while customers browse elsewhere.

Conclusion

Unsecured cookies may potentially provide a security risk to website owners and users. The original website or a third party receives unencrypted data about an insecure cookie over HTTP. That’s a low danger if the information is something straightforward, like if the person has already visited the site. Some websites, however, may use cookies to store user data, including personally identifying information such as login passwords and payment card details. Unencrypted transmissions of such kind of data leave them open to interception and misuse by criminals. A secure cookie only permits the transmission of cookie data via HTTPS and does not carry the same danger.

The post What is Cookies and Why it is Used? appeared first on scmGalaxy.

By default docker use https to connect to docker registry. But there can be use cases to use insecure registry. Here are the steps to use insecure registry.

In ubuntu
edit the file /etc/default/docker and update DOCKER_OPTS e.g

DOCKER_OPTS='--insecure-registry 10.84.34.155:5000'

where 10.84.34.155 is ipaddress of registry and 5000 is your port on which registry is configured.

In Centos
Edit the file /etc/docker/daemon.json e.g.

{
"insecure-registries" : ["10.84.34.155:5000"]
}

where 10.84.34.155 is ipaddress of registry and 5000 is your port on which registry is configured.

Restart docker
$ service docker restart

The post Setup Docker service to use insecure(http) registry instead of https appeared first on scmGalaxy.

The other main standard that controls how the World Wide Web works is HTML, which covers how Web pages are formatted and displayed.

HTTP is called a stateless protocol because each command is executed independently, without any knowledge of the commands that came before it.

The post What is HTTP (HyperText Transfer Protocol) appeared first on scmGalaxy.

Apache and HTTP Interview Questions and Answers – Interview Guide

List of Apache and HTTP Interview Questions: –

<!– /* Font Definitions */ @font-face {font-family:”Cambria Math”; panose-1:2 4 5 3 5 4 6 3 2 4; mso-font-charset:1; mso-generic-font-family:roman; mso-font-format:other; mso-font-pitch:variable; mso-font-signature:0 0 0 0 0 0;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4; mso-font-charset:0; mso-generic-font-family:swiss; mso-font-pitch:variable; mso-font-signature:-1610611985 1073750139 0 0 159 0;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {mso-style-unhide:no; mso-style-qformat:yes; mso-style-parent:””; margin-top:0in; margin-right:0in; margin-bottom:10.0pt; margin-left:0in; line-height:115%; mso-pagination:widow-orphan; font-size:11.0pt; font-family:”Calibri”,”sans-serif”; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:Calibri; mso-fareast-theme-font:minor-latin; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:”Times New Roman”; mso-bidi-theme-font:minor-bidi;} .MsoChpDefault {mso-style-type:export-only; mso-default-props:yes; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:Calibri; mso-fareast-theme-font:minor-latin; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:”Times New Roman”; mso-bidi-theme-font:minor-bidi;} .MsoPapDefault {mso-style-type:export-only; margin-bottom:10.0pt; line-height:115%;} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in; mso-header-margin:.5in; mso-footer-margin:.5in; mso-paper-source:0;} div.Section1 {page:Section1;} /* List Definitions */ @list l0 {mso-list-id:1388797391; mso-list-template-ids:-480605428;} ol {margin-bottom:0in;} ul {margin-bottom:0in;} –>

1. On a fresh install, why does Apache have three config files – srm.conf, access.conf and httpd.conf? – The first two are remnants from the NCSA times, and generally you should be ok if you delete the first two, and stick with httpd.conf.
2. What’s the command to stop Apache? – kill the specific process that httpd is running under, or killall httpd. If you have apachectl installed, use apachectl stop.
3. What does apachectl graceful do? – It sends a SIGUSR1 for a restart, and starts the apache server if it’s not running.
4. How do you check for the httpd.conf consistency and any errors in it? – apachectl configtest
5. When I do ps -aux, why do I have one copy of httpd running as root and the rest as nouser? – You need to be a root to attach yourself to any Unix port below 1024, and we need 80.
6. But I thought that running apache as a root is a security risk? – That one root process opens port 80, but never listens to it, so no user will actually enter the site with root rights. If you kill the root process, you will see the other kids disappear as well.
7. Why do I get the message “… no listening sockets available, shutting down”? – In Apache 2 you need to have a listen directive. Just put Listen 80 in httpd.conf.
8. How do you set up a virtual host in Apache?
   <VirtualHost www.techinterviews.com>
   ServerAdmin admin@techinterviews.com
   DocumentRoot /home/apache/share/htdocs/hostedsites
   ServerName www.techinterviews.com
   ErrorLog /home/apache/logs/error/hostedsites/error_log
   TransferLog /home/apache/logs/access/hostedsites/access_log
   </VirtualHost>
9. What is ServerType directive? – It defines whether Apache should spawn itself as a child process (standalone) or keep everything in a single process (inetd). Keeping it inetd conserves resources. This is deprecated, however.
10. What is mod_vhost_alias? – It allows hosting multiple sites on the same server via simpler configurations.
11. What does htpasswd do? – It creates a new user in a specified group, and asks to specify a password for that user.
12. If you specify both deny from all and allow from all, what will be the default action of Apache? – In case of ambiguity deny always takes precedence over allow.

The post Apache and HTTP Interview Questions and Answers – Interview Guide appeared first on scmGalaxy.